---

Nu har jeg pligtskyldigt forsøgt at validere en enkelt af mine sider - men
følger man reglerne støder man konstant på forhindringer, der tilsyneladende
ikke lader sig løse tilfredsstillende.

Det må man ikke - og hvad så?

Et af de problemer jeg er stødt på - og hoppet hen over med den løsning jeg
kunne finde - er de(t) linieskift der opstår i forbindelse med FORM-tag.

Hidtil har jeg "gemt" disse i tabeltags - men den går jo ikke ;-((

Hvad hulen gør man så?

Jo, man skal bar bruge style siger klåge Åge! - desværre virker dette heller
;-((

Så, hvem kan/vil svare på dette teoretiske spørgsmål, der ikke er forbundet
med noget bestemt, og derfor heller ikke kan sidehenvises.

Hvorfor i alverden laver FORM-tag et linieskift?
Hvorfor kan FORM ikke nestes med TABLE eller DIV?

Vel, det er der jo en browser der kan - er det så den der er super, erller
de andre der er dukse?

Ja unskyld - jeg spørger blot.

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen wrote:
> Nu har jeg pligtskyldigt forsøgt at validere en enkelt af mine sider - men
> følger man reglerne støder man konstant på forhindringer, der tilsyneladende
> ikke lader sig løse tilfredsstillende.

Dit problem kan sagtens løses

>
> Det må man ikke - og hvad så?

Ja, så ikke så meget, det er op til dig om du vil følge standarderne
eller ej.

>
> Et af de problemer jeg er stødt på - og hoppet hen over med den løsning jeg
> kunne finde - er de(t) linieskift der opstår i forbindelse med FORM-tag.
>
> Hidtil har jeg "gemt" disse i tabeltags - men den går jo ikke ;-((

Hidtil... var den måde man gjorde det på i gamle dage... altså i forrige
årtusinde

>
> Hvad hulen gør man så?

Benytter CSS.

>
> Jo, man skal bar bruge style siger klåge Åge! - desværre virker dette heller
> ;-((

Hvad har du gjort? Må vi se et link til et online eksempel.

>
> Så, hvem kan/vil svare på dette teoretiske spørgsmål, der ikke er forbundet
> med noget bestemt, og derfor heller ikke kan sidehenvises.
>
> Hvorfor i alverden laver FORM-tag et linieskift?

Fordi der er en margin og evt. en smule padding.

Nulstil margin og paddin på form elementet.

form {
margin:0;
padding:0;
}

> Hvorfor kan FORM ikke nestes med TABLE eller DIV?

Øh...neste?
Du må _ikke_ smide form lige efter du har startet et table element.
<table><form ...
Men du må godt smide det inde i et td element.

Og du må sagtens smide form i et div element
<div><form ...


>
> Vel, det er der jo en browser der kan - er det så den der er super, erller
> de andre der er dukse?
>
> Ja unskyld - jeg spørger blot.
>

Det er i orden du spørger

--
Martin Hintzmann
http://www.hintzmann.dk/

---

Martin Hintzmann skrev:

> Øh...neste?

Anglicisme for indlejre.

> Du må _ikke_ smide form lige efter du har startet et table
> element. <table><form ...
> Men du må godt smide det inde i et td element.

Hvis man har brug for en form der spænder over flere tabelceller,
skal form-elementet indlejre table-elementet:

<form...><table>


> Og du må sagtens smide form i et div element
> <div><form ...

Jep - lige som det omvendte også er tilladt: <form...><div>
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns96C34FE4EE9Fjcdmfdk@gyrosmod.cybercity.dk...

> Hvis man har brug for en form der spænder over flere
> tabelceller, skal form-elementet indlejre table-elementet:

Ja, det var jo det jeg havde konstateret - og dermed forsvandt den, ganske
vist ulovlige, metode til at undgå det tåbelige linieskift.

Heldigvis fantes løsningen, men nogen gange koster det jo hårpragten at
finde den

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

"Martin Hintzmann" <no@spam.invalid> skrev i en meddelelse
news:4314d302$0$18644$14726298@news.sunsite.dk...
> form { margin:0; padding:0; }

Jeg må bøje mig - det virker - tak

Jeg kan så undre mig over, at det ikke er deault - men det er ikke det
eneste default-værdi, der imho er helt go'nat.

Men, så er der lige problemet med %-angivelser på billeder i tabeller.

Uden for kan man altid scalere sit billede, men ikke i tabelceller eller
andre variable kasse-tags.

Det kan CSS vel ikke klare også?

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen wrote:
>
> Jeg kan så undre mig over, at det ikke er deault - men det er ikke det
> eneste default-værdi, der imho er helt go'nat.
>

Personligt synes jeg det er rart at der er lidt luft imellem elementerne
på siden.
Så hvis man ser et råt og usødet HTML-doklument, så vil der som standard
være lidt afstand imellem en liste, en form, en tabel o.s.v.

Samme mening har W3C og browser producenterne åbentbart også.

Så det er op til dig som web-designer at fjerne de mellemrum du ikke er
interesseret i.


> Men, så er der lige problemet med %-angivelser på billeder i tabeller.
>
> Uden for kan man altid scalere sit billede, men ikke i tabelceller eller
> andre variable kasse-tags.
>
> Det kan CSS vel ikke klare også?
>

Jeg er ikke sikker på at jeg helt forstå det du skriver.
Kan du ikke komme med et online eksempel eller forklare det lidt mere.



--
Martin Hintzmann
http://www.hintzmann.dk/

---

"Martin Hintzmann" <no@spam.invalid> skrev i en meddelelse
news:4314e773$0$18640$14726298@news.sunsite.dk...

> Samme mening har W3C og browser producenterne åbentbart også.

Ja, men det finder jeg altså mærkeligt - men jeg er ofte uenige med dem på
bjerget )

> Jeg er ikke sikker på at jeg helt forstå det du skriver.
> Kan du ikke komme med et online eksempel eller forklare det lidt mere.

Nix - jeg kan skære det ud i pap:

Uanset vinduets tilfældighed ønskes 4 (løse) billeder, der er vertikal uens,
men parvis lige høje, bibeholde sine proportioner og fylde skærmen
horisontalt.

aa bb
cc bb
cc dd

Hvordan undgår man at det bliver:

aa bb
bb
cc
cc dd

Jeg har forsøgt med float:left/right i 117 forskellige konstellationer,
men...

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen wrote:
>
> Jeg har forsøgt med float:left/right i 117 forskellige konstellationer,
> men...
>

Jeg ville smide billederne parvis i et div element, og så have en
wrapper uden om samtlige div elementer, med en fast width. billederne
vil jeg så floate left, og sætte overflow hidden på div elementerne.

--
Martin Hintzmann
http://www.hintzmann.dk/

---

"Martin Hintzmann" <no@spam.invalid> skrev i en meddelelse
news:4315c83d$0$18644$14726298@news.sunsite.dk...

> Jeg ville smide billederne parvis i ...

Det løser ikke problemet med billederne, der gerne skulle fylde en
hvilkensomhelst skærm/vinduesstørrelse ud.

som Johnny Winther Ronnenberg skriver:

> Desværre nej, når man angiver størrelsen på et billede
> i procenter hvilket man godt kan i både HTML og CSS så er størrelsen i
> forhold til billedet

Og med den viden kan det jo forkastes som umuligt.

Der er dog ikke så naglefast, at man ikke kan tage fejl, for det lader sig
jo de facto gøre at scalere et billede med pocentangivelser. Det er først
når man forsøger at styer placeringerne, at det går galt. At det så ikke er
anerkendt metodik er noget helt andet.

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen wrote:
>
> Det løser ikke problemet med billederne, der gerne skulle fylde en
> hvilkensomhelst skærm/vinduesstørrelse ud.

Hvis du har en div der fylder 50% eller 100% af skærmens bredde og der i
har et billede der fylder 100% af div'ens bredde, så følger den
browserens størrelse.

Her er et eksempel på et billede der følger browserens størrelse.
http://www.hintzmann.dk/testcenter/css/bg_grid/index.html

Det er et gammelt eksempel til noget andet, så det er ikke noget jeg har
lavet for at vise det med parvise billeder.

>
> som Johnny Winther Ronnenberg skriver:
>
>
>>Desværre nej, når man angiver størrelsen på et billede
>>i procenter hvilket man godt kan i både HTML og CSS så er størrelsen i
>>forhold til billedet
>
>


Er det i forhold til at det godt kan lade sig gøre i en tabel, at du
tvivler på om det kan lade sig gøre i CSS... i så fald bliver du nød til
at vise et eksempel, hvor en tabel med billeder gør det du ønsker
Så vil jeg gerne prøve at gøre det med ren CSS.

Men jeg vil ikke gå igang, hvis jeg nu har misforstået noget.


> Og med den viden kan det jo forkastes som umuligt.
>
> Der er dog ikke så naglefast, at man ikke kan tage fejl, for det lader sig
> jo de facto gøre at scalere et billede med pocentangivelser. Det er først
> når man forsøger at styer placeringerne, at det går galt. At det så ikke er
> anerkendt metodik er noget helt andet.
>

Jeg vil mene at man sagtens kan scallere et billede og samtidig bestemme
dets placering.


--
Martin Hintzmann Andersen
http://www.hintzmann.dk/

---

"Martin Hintzmann Andersen" <no@spam.invalid> skrev i en meddelelse
news:4316ee0e$0$18646$14726298@news.sunsite.dk...
> Her er et eksempel på et billede der følger browserens størrelse.
> http://www.hintzmann.dk/testcenter/css/bg_grid/index.html

Spændende eksempel - det vil jeg arbejde lidt med, tak.

> Men jeg vil ikke gå igang, hvis jeg nu har misforstået noget.

I princippet er jeg ligeglad hvordan det løses - men jeg kan da se der er
flere muligheder i CSS end de der er umiddelbart tilgængelige.

> Jeg vil mene at man sagtens kan scallere et billede
> og samtidig bestemme dets placering.

Det kan man - men det der er pointen er det skal være i procent af det
ukendte vindue - men det har du jo lige givet eksempel på ikke er umuligt.

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

In news:<4314e3e2$0$22479$edfadb0f@dread16.news.tele.dk>
Poul Erik Jensen typed:
> Men, så er der lige problemet med %-angivelser på billeder i tabeller.
>
> Uden for kan man altid scalere sit billede, men ikke i tabelceller
> eller andre variable kasse-tags.
>
> Det kan CSS vel ikke klare også?

Desværre nej, når man angiver størrelsen på et billede i procenter
hvilket man godt kan i både HTML og CSS så er størrelsen i forhold til
billedet.

Så hvis et billede er 200px bredt og vi sætter bredden til 50% så bliver
billedet vist som om det var 100px bredt men hvis tabelcellen kun er
75px bred, ja så udvides tabellen, så billedet kan fylde det vi har sat
det til. Det er altså billedets størrelsesforhold man stiller på og ikke
dets forhold til det omgivende element. Men det kan heller ikke gøres i
ren HTML så CSS har ikke skylden

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg wrote:
>
> Desværre nej, når man angiver størrelsen på et billede i procenter
> hvilket man godt kan i både HTML og CSS så er størrelsen i forhold til
> billedet.
>
> Så hvis et billede er 200px bredt og vi sætter bredden til 50% så bliver
> billedet vist som om det var 100px bredt men hvis tabelcellen kun er
> 75px bred, ja så udvides tabellen, så billedet kan fylde det vi har sat
> det til. Det er altså billedets størrelsesforhold man stiller på og ikke
> dets forhold til det omgivende element. Men det kan heller ikke gøres i
> ren HTML så CSS har ikke skylden
>

Enten har du eller også har jeg misforstået et eller andet.

Men...

hvis jeg sætter 50% bredde på et billede, er det ikke i forhold til
billedets original størrelse, men i forhold til den parent element, som
f.eks. kunne være browser vinduet.

Se følgende eksempel
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/index.html

Her har jeg sat billedet med 50% højde og bredde på billedet, og både
Firefox, Opera og IE, viser det i forhold til browser vinduet.


--
Martin Hintzmann Andersen
http://www.hintzmann.dk/

---

In news:<4316f20b$0$18640$14726298@news.sunsite.dk>
Martin Hintzmann typed:
> Johnny Winther Ronnenberg wrote:
>>
>> Desværre nej, når man angiver størrelsen på et billede i procenter
>> hvilket man godt kan i både HTML og CSS så er størrelsen i forhold
>> til billedet.
>>
>> Så hvis et billede er 200px bredt og vi sætter bredden til 50% så
>> bliver billedet vist som om det var 100px bredt men hvis tabelcellen
>> kun er 75px bred, ja så udvides tabellen, så billedet kan fylde det
>> vi har sat det til. Det er altså billedets størrelsesforhold man
>> stiller på og ikke dets forhold til det omgivende element. Men det
>> kan heller ikke gøres i ren HTML så CSS har ikke skylden
>>
>
> Enten har du eller også har jeg misforstået et eller andet.
>

En lille rettelse IE 6 vil nu godt skalere billedet i forhold tildet
størrelse mren anbragt i en tabelcelle så udvides cellen til billedets
egentlige størrelse og ikke til den beregnede.

> Men...
>
> hvis jeg sætter 50% bredde på et billede, er det ikke i forhold til
> billedets original størrelse, men i forhold til den parent element,
> som f.eks. kunne være browser vinduet.
>
> Se følgende eksempel
>
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/index.html
>
> Her har jeg sat billedet med 50% højde og bredde på billedet, og både
> Firefox, Opera og IE, viser det i forhold til browser vinduet.

Jeg har også et lille eksempel som er både valid i HTML og CSS og
browserne forstår det ikke, helt så godt som man kunne forvente.

Faktisk er de rygende uenige om hvordan det skal se ud

http://80.62.61.212/test/billedprocent.htm

Mens jeg har fat i dig, du viste på et tidspunkt et 1-3-1 layout der var
skalerbart via css hacks, hvis du kunne lokkes til at give et link til
det, så vil jeg gerne have et ekstra kig på det.

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg wrote:
>
> Jeg har også et lille eksempel som er både valid i HTML og CSS og
> browserne forstår det ikke, helt så godt som man kunne forvente.
>
> Faktisk er de rygende uenige om hvordan det skal se ud
>
> http://80.62.61.212/test/billedprocent.htm
>

Ja, jeg kan godt set at browserne er meget uenige i dit eksempel.

Men meget af det skyldes at der ikke er angivet height på parent
elementerne, og derved skal browserne til at gætte.

Hvis du i eksemplet tilføjer height 100% på html, body og tabel, så er
forskellen lige pludselig betydligt formindsket.
Firefox, Opera og Safari viser billederne ens i både height og width.

(Safari aligner dog billederne i toppen af td elementerne istedet for i
midten, som de to øvrige browsere. Men det kan hurtigt fikses med
"vertical-align".)

IE6 viser width på billederne som i de øvrige browsere, men har stadig
lidt problemer med height... Så tjaaa...

Jeg vil give dig ret i at det ikke ser 100% ens ud, men det er stort set
kun IE6 der træder ved siden af... så rygende uenige vil jeg ikke sige
at browserne er.

Men lad os håbe at det bliver rettet i IE7 (Lidt optimist er man vel altid)



> Mens jeg har fat i dig, du viste på et tidspunkt et 1-3-1 layout der var
> skalerbart via css hacks, hvis du kunne lokkes til at give et link til
> det, så vil jeg gerne have et ekstra kig på det.
>

Er det den her du mener ?
http://www.hintzmann.dk/testcenter/css/center_layout/default.html

Eller var det den her ?
http://www.hintzmann.dk/testcenter/css/3spalte/

Eller et helt tredje... så vil jeg da prøve at finde det


--
Martin Hintzmann
http://www.hintzmann.dk/

---

In news:<43177ab8$0$18642$14726298@news.sunsite.dk>
Martin Hintzmann typed:
> Johnny Winther Ronnenberg wrote:
>>
>> Jeg har også et lille eksempel som er både valid i HTML og CSS og
>> browserne forstår det ikke, helt så godt som man kunne forvente.
>>
>> Faktisk er de rygende uenige om hvordan det skal se ud
>>
>> http://80.62.61.212/test/billedprocent.htm
>>
>
> Ja, jeg kan godt set at browserne er meget uenige i dit eksempel.
>
> Men meget af det skyldes at der ikke er angivet height på parent
> elementerne, og derved skal browserne til at gætte.
>
> Hvis du i eksemplet tilføjer height 100% på html, body og tabel, så er
> forskellen lige pludselig betydligt formindsket.
> Firefox, Opera og Safari viser billederne ens i både height og width.
>

Både med og uden heigth på parent, fejl formater OP og FF billedets
størrelsesforhold, det gør IE rigtigt både med og ude heigth på html og
body, til gengæld fejler IE når man sætter height på tabellen. og den
formaterer stadig tabellen forkert.

> (Safari aligner dog billederne i toppen af td elementerne istedet for
> i midten, som de to øvrige browsere. Men det kan hurtigt fikses med
> "vertical-align".)
>
> IE6 viser width på billederne som i de øvrige browsere, men har stadig
> lidt problemer med height... Så tjaaa...
>

Det kan jeg godt nok ikke se, måske jeg skrøve et andet billede hvor
forskydningen bedre ses.

> Jeg vil give dig ret i at det ikke ser 100% ens ud, men det er stort
> set kun IE6 der træder ved siden af... så rygende uenige vil jeg ikke
> sige
> at browserne er.
>

Selv med heigth på parent elementer er det ubrugeligt set rent
designmæssigt, Men med de rigtige hacks kan det måske sættes til at
fungere.

> Men lad os håbe at det bliver rettet i IE7 (Lidt optimist er man vel
> altid)
>
Jo men vi slås stadig med IE og NS 5 så hvad glæde har vi af at nye
versioner, der fortolker standarderene bedre, når vi samtidig skal være
bag kompatible
>
>
>> Mens jeg har fat i dig, du viste på et tidspunkt et 1-3-1 layout der
>> var skalerbart via css hacks, hvis du kunne lokkes til at give et
>> link til det, så vil jeg gerne have et ekstra kig på det.
>>
>
> Er det den her du mener ?
> http://www.hintzmann.dk/testcenter/css/center_layout/default.html
>
> Eller var det den her ?
> http://www.hintzmann.dk/testcenter/css/3spalte/
>
> Eller et helt tredje... så vil jeg da prøve at finde det

Nej det var ikke nogen af dem, du viste på et tidspunkt et layout der
opførte nøjagtig som en tabel, både ved skiftende skærmstørrelser og
vinduesstørrelser, det var ikke validt for der var hacks i CSS både for
IE og OP og hvis jeg husker rigtigt en browser mere. Jeg kan huske det,
fordi det er den eneste gang, jeg har set et divlayout der rent faktisk
var fuldt skalerbart.

Denne tråd mindede mig om det, fordi det sikkert holdt løsningen på
problemet. Men det links jeg havde smidt på skrivebordet havde jeg i
mellemtiden slettet under en oprydning ;-(

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg <johnny.winther@XYZ789tdcadsl.dk> skrev:

>>> http://80.62.61.212/test/billedprocent.htm

> Både med og uden heigth på parent, fejl formater OP
> og FF billedets størrelsesforhold, det gør IE rigtigt

Jeg kan ikke tro at nogen i den vildeste fantasi vil lave
sin hjemmeside med skalerbare billeder i tabelceller
eller med skalerbare billeder i det hele taget.

Alle der prøver kan jo se at billedet mister en stor del af
sin kvalitet ved at blive skaleret op eller ned, så jeg forstår
ikke at I ofrer så meget tid på det.

> at nye versioner, der fortolker standarderene bedre, når
> vi samtidig skal være bag kompatible

Hvis Microsoft skal følge med, skal de nok bestille arbejdet
ude i byen

> Denne tråd mindede mig om det, fordi det sikkert...

Jeg kan heller ikke huske tråden. Var det i denne gruppe?
Kan du huske noget fra den, kan det måske findes ved at
søge efter det.

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

---

Johnny Winther Ronnenberg wrote:
>
> Både med og uden heigth på parent, fejl formater OP og FF billedets
> størrelsesforhold, det gør IE rigtigt både med og ude heigth på html og
> body, til gengæld fejler IE når man sætter height på tabellen. og den
> formaterer stadig tabellen forkert.
>

Det vil jeg ikke mene at de gør i dette omskrevet eksempel
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/index2.html

Nu kommer det jo også an på hvordan man vil mene at det bør se ud...
Jeg har ikke tjecket standarderne for hvordan det bør se ud.
Men jeg vil da mene at billedet med class'en .half bør fylde det halve
af TD elementet, hvilket den også gør på følgende 3 screenshots.

http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/firefox.gif
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/opera.gif
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/safari.gif

IE laver den til 1/4-del, hvilket jeg ville mene var forkert.
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/ie.gif

3 forskellige browsere er enige, IE er ikke. Jeg vil mene at det er IE
der er på afveje.

>
> Det kan jeg godt nok ikke se, måske jeg skrøve et andet billede hvor
> forskydningen bedre ses.
>

Tag et kig igen på det her screenshot.
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/ie.gif

>
> Selv med heigth på parent elementer er det ubrugeligt set rent
> designmæssigt, Men med de rigtige hacks kan det måske sættes til at
> fungere.
>

Man kan sikkert lave nogle CSS-hacks specielt til IE, så den viser dit
eksempel som de andre.

Dit eksempel med at billeder i tabeller bliver vist forskelligt, er jeg
ikke stødt på i mit daglige arbejde... Jeg har skippet TABEL-layouts til
fordel for rene CSS-layouts.

Så hvis ovenstående er et problem for dig eller andre, vil jeg da
anbefale at I skipper tabeller til at positionere jeres sider.

>
> Jo men vi slås stadig med IE og NS 5 så hvad glæde har vi af at nye
> versioner, der fortolker standarderene bedre, når vi samtidig skal være
> bag kompatible
>

Den eneste browser jeg slås med er IE. Når jeg har lavet en side efter
standarderne, så ser den 99% af gangene ens ud i Firefox, Opera og Safari.

IE skal altid have noget speciel hjælp. Hvis det tager mig 5 timer at
lave et layout, så skal jeg altid huske at lægge 20% oven i, hvis det
også skal se pænt ud i IE.


>
> Nej det var ikke nogen af dem, du viste på et tidspunkt et layout der
> opførte nøjagtig som en tabel, både ved skiftende skærmstørrelser og
> vinduesstørrelser, det var ikke validt for der var hacks i CSS både for
> IE og OP og hvis jeg husker rigtigt en browser mere.

Pas
Jeg kan desværre ikke huske det. Kommer jeg i tanke om det skal jeg nok
poste i gruppen.

--
Martin Hintzmann
http://www.hintzmann.dk/

---

In news:<4318c3ec$0$18642$14726298@news.sunsite.dk>
Martin Hintzmann typed:
> Johnny Winther Ronnenberg wrote:
>>
>> Både med og uden heigth på parent, fejl formater OP og FF billedets
>> størrelsesforhold, det gør IE rigtigt både med og ude heigth på html
>> og body, til gengæld fejler IE når man sætter height på tabellen. og
>> den formaterer stadig tabellen forkert.
>>
>
> Det vil jeg ikke mene at de gør i dette omskrevet eksempel
>
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/index2.html
>
> Nu kommer det jo også an på hvordan man vil mene at det bør se ud...

Måske du skulle overveje at anskalffe dig et par briller for, det kniber
stadig med skaleringen alle steder, selv jeg kan se dig. Og hvis jeg kan
se det vil det afføde mere edn 200 indlæg i gruppen, Hvorfor virker det
ikke i...

> Jeg har ikke tjecket standarderne for hvordan det bør se ud.

Det tror jeg ikke standarderne har noget brugbart bud på

> Men jeg vil da mene at billedet med class'en .half bør fylde det halve
> af TD elementet, hvilket den også gør på følgende 3 screenshots.
>
>
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/firefox.gif
> http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/opera.gif
>
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/safari.gif
>
> IE laver den til 1/4-del, hvilket jeg ville mene var forkert.
> http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/ie.gif
>
> 3 forskellige browsere er enige, IE er ikke. Jeg vil mene at det er IE
> der er på afveje.
>
>>
>> Det kan jeg godt nok ikke se, måske jeg skrøve et andet billede hvor
>> forskydningen bedre ses.
>>
>
> Tag et kig igen på det her screenshot.
> http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/ie.gif
>

Det kan godt være at det er mine briller der spiller mig et puds men det
virker som om billederne er en anelse mere end smule fejlproportioneret


>
> Dit eksempel med at billeder i tabeller bliver vist forskelligt, er
> jeg ikke stødt på i mit daglige arbejde... Jeg har skippet
> TABEL-layouts til fordel for rene CSS-layouts.
>

Nu skal vi lige huske på at CSS er en udvidelse af HTML ikke en ny
verdensorden hvilket selv fejedyret Meyer indrømmer, han bruger oven i
købet tabeller selv, hvilket har været oppe i i webdesigngrupperne flere
gange som oftes som kritik.

> Så hvis ovenstående er et problem for dig eller andre, vil jeg da
> anbefale at I skipper tabeller til at positionere jeres sider.
>

Med fare for en hellig krig, jeg er ikke nogen stor fortaler for
tabeller, men brugt korrekt så udgør de ingen problemer, hverken
layoutmæssigt, eller tilgængelighedsmæssigt, der eksistere en række
fordomme som er svære at mane i jorden, men rent teknisk er der ingen
problemer, hvis man holder sig til standarderne. Det eneste problem man
altid har, er på browsersiden, men der har div de samme problemer, der
er simpelthen områder, som browserne fortolker så forskelligt at
produktet bliver ubrugeligt. Vores lille leg med billeder her, viser det
ret tydeligt. Det vi har præsteret her vil aldrig tilfredstille en
grafiker, det vil ikke engang tilfredstille mig, Vi skal bare huske, at
det vi præsenterer, ikke nødvendigvis opfattes ens i browserene.

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg <johnny.winther@XYZ789tdcadsl.dk> skrev:

> Det kan godt være at det er mine briller der spiller
> mig et puds

Så puds dem

> ikke nogen stor fortaler for tabeller...
>
> rent teknisk er der ingen problemer

Vi ser bare så tit tabeller i tabeller i tabeller, så det til
sidst bliver en pestilens at opdatere siden. Gør du noget
et sted, har det straks indflydelse på alt det andet, og så
kommer alle spørgsmålene i webdesign-grupperne.

Jo, man kan sagtens lave et fint design med tabeller og
valid kode, men nu er det pludselig designet der bliver en
spændetrøje - især hvis der skal ændres i det.

> der har div de samme problemer, der er simpelthen
> områder, som browserne fortolker så forskelligt at
> produktet bliver ubrugeligt

Kan du give et eksempel? En <div> kan man flytte rundt
på med css - det er ikke lige så nemt med en tabelcelle
uden at det går ud over de andre celler i tabellen.

Jeg mener at et layout med <div> fremfor <table> er meget
mere fleksibelt.

Jeg sætter opfølgning til news:dk.edb.internet.webdesign,
da debatten ikke ikke har meget med clientside at gøre.

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

---

Johnny Winther Ronnenberg wrote:
>
> Måske du skulle overveje at anskalffe dig et par briller for, det kniber
> stadig med skaleringen alle steder, selv jeg kan se dig. Og hvis jeg kan
> se det vil det afføde mere edn 200 indlæg i gruppen, Hvorfor virker det
> ikke i...
>

Johnny... hvis du kigger på de her to screenshot, kan du så ikke se at
bredden og vidten på billederne er fuldstændig ens i de to browsere?

http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/opera.gif
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/firefox.gif

Det er rigtigt at skalleringen af selve billedet er lidt flossen i
kanten i Firefox, men jeg har hele tiden troede at vi har snakket om
width og height på billedet og ikke kvaliteten af billedet efter skallering.

- Eller hvad ?

IE er da fuldstændige ude i skoven...
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/ie.gif

Billedet i midten er da helt forkert trykket sammen i højden.
Du må tage pis på mig hvis du siger at du ikke kan se at det er IE der
er problem barnet her.


>
> Det kan godt være at det er mine briller der spiller mig et puds men det
> virker som om billederne er en anelse mere end smule fejlproportioneret
>
>

Ja, IE er meget afvigende fra de andre browsere.
De øvrige ligner da meget godt hindanden, når man tager højde for at
selve pladsen til indholdet jo ikke er 100% ens fra browser til browser,
nogle har tabs og status bar o.s.v. som optager noget af skærm pladsen.

>
>
> Nu skal vi lige huske på at CSS er en udvidelse af HTML ikke en ny
> verdensorden hvilket selv fejedyret Meyer indrømmer, han bruger oven i
> købet tabeller selv, hvilket har været oppe i i webdesigngrupperne flere
> gange som oftes som kritik.
>

Hvis du har oplevet problemer med skaleringen af billeder i tabeller, så
forstår jeg ikke at du stadig vil bruge dem?



--
Martin Hintzmann
http://www.hintzmann.dk/

---

In news:<431be60a$0$18648$14726298@news.sunsite.dk>
> Johnny... hvis du kigger på de her to screenshot, kan du så ikke se at
> bredden og vidten på billederne er fuldstændig ens i de to browsere?
>
> http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/opera.gif
>
http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/firefox.gif
>
> Det er rigtigt at skalleringen af selve billedet er lidt flossen i
> kanten i Firefox, men jeg har hele tiden troede at vi har snakket om
> width og height på billedet og ikke kvaliteten af billedet efter
> skallering.
>
> - Eller hvad ?

Det er faktisk skaleringen der er problemet.

>
> IE er da fuldstændige ude i skoven...
> http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/ie.gif
>
> Billedet i midten er da helt forkert trykket sammen i højden.
> Du må tage pis på mig hvis du siger at du ikke kan se at det er IE der
> er problem barnet her.
> '

Så vidt jeg kan se har de problemer allesammen med at holde
proportionerne. hvilket knyttet sig til hvad de opfatter som en
container.

>
>>
>> Det kan godt være at det er mine briller der spiller mig et puds men
>> det virker som om billederne er en anelse mere end smule
>> fejlproportioneret
>>
>
> Ja, IE er meget afvigende fra de andre browsere.
> De øvrige ligner da meget godt hindanden, når man tager højde for at
> selve pladsen til indholdet jo ikke er 100% ens fra browser til
> browser, nogle har tabs og status bar o.s.v. som optager noget af
> skærm pladsen.
>

Igen hvad er elementet indholdt i? Det skaber problemet.

>>
>>
>> Nu skal vi lige huske på at CSS er en udvidelse af HTML ikke en ny
>> verdensorden hvilket selv fejedyret Meyer indrømmer, han bruger oven
>> i købet tabeller selv, hvilket har været oppe i i webdesigngrupperne
>> flere gange som oftes som kritik.
>>
>
> Hvis du har oplevet problemer med skaleringen af billeder i tabeller,
> så forstår jeg ikke at du stadig vil bruge dem?

Nu det er i øvrigt ikke mig, men Poul Erik Jensen der ønsker at bruge
tabeller og CSS og kunne validere! Hvilket er et meget stort skridt i
forhold til de første tråde han startede. I mit oprindelige svar på hans
spørgsmål, svarede jeg at det ikke kunne lade sig gøre i al fald ikke
validt, det vil kræve hacks i CSS hvis det skal være funktionelt og
dermed er det ikke validt. Og som nogle stykker måske har opdaget, så
vil jeg også gerne have, at sider validerer efter nogle lidt snævrere
regler, hvilket kræver valid HTML og CSS.

Med venlig hilsen
Johnny Winther Ronnenberg


--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg wrote:
>
> Det er faktisk skaleringen der er problemet.
>

Du startede tråden ud med følgende:
"Så hvis et billede er 200px bredt og vi sætter bredden til 50% så
bliver billedet vist som om det var 100px"

Hvilket ikke er rigtigt, det vil være 50% af dens parent element. Og
derfra har jeg hele tiden trodet at vi snakkede om størrelses forholdet,
altså dimensionen (width og height), og ikke kvaliteten af det op eller
ned skalleret billede.
Men dertil kan jeg kun give dig ret, browserne har forskellige
algoritmer som ikke alle er lige gode.

>
> Så vidt jeg kan se har de problemer allesammen med at holde
> proportionerne. hvilket knyttet sig til hvad de opfatter som en
> container.
>

Proportionerne har jo ikke noget at gøre med orginal billedet at gøre.
Det er i forhold til dets parent element. I det her tilfælde skal IMG
billedet være 50% af TD elementet.

http://www.hintzmann.dk/testcenter/usenet/css/procentbillede/firefox_maal.gif

På det her billede kan du se at TD er 630 x 420 og IMG er sat til 50%
height og width. Det vil sige at den skal være 315 x 210, hvilket den
sjovt nok er. Altså sætter Firefox rigtig width og height på billedet.

Husk at 50% ikke er 50% af orginal billedet, men af dens parent element.

Og det er kun IE der ikke kan finde ud af det.


--
Martin Hintzmann
http://www.hintzmann.dk/

---

Poul Erik Jensen skrev:

[default margin/padding > 0]

> Ja, men det finder jeg altså mærkeligt - men jeg er ofte
> uenige med dem på bjerget )

Jeg mener det ville være mærkeligt hvis standarden specificerede
margen og fyld til 0. Det ville nemlig betyde at en side uden css-
kode ville se ret grim ud - fordi teksten ville starte helt ude i
venstre kant (og helt oppe fra toppen af siden).

Standardværdierne er med vilje valgt således at en side helt uden
css-koder stadig bliver formateret nogenlunde fornuftigt. Det gør
det let for folk at skrive websider - man behøver ikke at bekymre
sig om ting som margen hvis man ikke har brug for det.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns96C3B13528155jcdmfdk@gyrosmod.dtext.news.tele.dk...

> Jeg mener det ville være mærkeligt hvis standarden
> specificerede ....

Jamen, det er da heller ikke forkert at have den mening - slet ikke ud fra
dine premisser. Det modsatte kan vel alligevel være lige så legal en
opfattelse.

Men, bevares, når man nu skal tilgodese hr. massen og den almene aversion
mod individualitet, så er standarden jo forklarlig

Nogle af de fejlmeddelelser, der kommer fra W3C er så uforståelige, at det
kan være tæt på en umulig opgave at løse. Jeg ved naturligvis godt, at en
karakter ikke nødvendigvis er den samme, selvom den ser magen til ud, men
det tog mig alligevel en rum tid at skifte en hyphen ud med den godkendte
slags. Og fejlmeldingen kom i byger - på samme fejl.

Nu har jeg så kæmpet i to dage med at validere een side, men jeg kan ikke
komme ud over de sidste 6. Det er danske karaktere i statuslinien, hvor man
ikke kan benytte de anerkente &aelig; etc. og derfor tvinges til enten at
droppe statusmeddelelser med danske karakterer, eller se stort på
valideringen. Du vil naturligvis plædere for, at det er noget pjat at skrive
i statuslinien - men kan det forklares teknisk hvorfor det hænger sådan
sammen eller er der ligefrem en måde at løse problemet?

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen skrev:

> Jamen, det er da heller ikke forkert at have den mening - slet
> ikke ud fra dine premisser. Det modsatte kan vel alligevel
> være lige så legal en opfattelse.

Naturligvis er det legalt at mene som du gør. Jeg mener bare at der
er mange gode grunde til at standarden er bygget op som den er.


> Men, bevares, når man nu skal tilgodese hr. massen og den
> almene aversion mod individualitet, så er standarden jo
> forklarlig

Prøv at lave et nyt dokument i en tekstbehandler. Er margener dér
som standard 0? Nej, de har naturligvis nogle rimelige
standardværdier. Hvad med fontstørrelse, fonttype, skriftfarve,
linjeafstand og lignende - tænk hvis man var nødt til at vælge
disse størrelser før man kunne komme i gang med at skrive sin
tekst. Jeg tror ikke der er ret mange der vil ønske at have det
sådan.

Jeg kan ikke se at gængse standardværdier for opsætningen af en
side skulle virke hæmmende for individualiteten. Det betyder at man
har et (nogenlunde) fornuftigt udgangspunkt når man starter.

> Nogle af de fejlmeddelelser, der kommer fra W3C er så
> uforståelige, at det kan være tæt på en umulig opgave at løse..

Der er givetvis stadig fejlmeddelelser der kan forbedres, men en
del af forståelsen kommer nu også når man får lidt erfaring med
validatoren.

Kom med nogle eksempler på fejlmeddelelser der virker uforståelige
(sammen med den side der indeholder fejlen) - chancen for at
meddelelsen kan forstås og forklares af en anden i gruppen er
ganske høj.


> Jeg ved naturligvis godt, at en karakter ikke nødvendigvis er
> den samme, selvom den ser magen til ud, men det tog mig
> alligevel en rum tid at skifte en hyphen ud med den godkendte
> slags. Og fejlmeldingen kom i byger - på samme fejl.

Sådan vil det ofte være - men har man først fundet ud af at det fx
er en "forkert" bindestreg der fejler, er det jo bare at bruge søg
og erstat for at få dem alle rettet.


> Nu har jeg så kæmpet i to dage med at validere een side, men
> jeg kan ikke komme ud over de sidste 6. Det er danske
> karaktere i statuslinien, hvor man ikke kan benytte de
> anerkente &aelig; etc. og derfor tvinges til enten at droppe
> statusmeddelelser med danske karakterer, eller se stort på
> valideringen.

Det lyder som et tegnsætsproblem - hvis du fx angiver utf8, men
skriver i latin-1. Lad os se siden - det er meget lettere at
bedømme et konkret problem.


> Du vil naturligvis plædere for, at det er noget
> pjat at skrive i statuslinien -

Nej - ikke før jeg har set hvad du bruger det til
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns96C46E53685D7jcdmfdk@gyrosmod.dtext.news.tele.dk...

> Prøv at lave et nyt dokument i en tekstbehandler. ...

Tja, det er jo ikke noget dårligt argument - selvom jeg også i det tilfælde
foretrækker selv at stille mine præmisser op )

> Kom med nogle eksempler ...

Det akuelle problem er på forsiden af www.skolekammeraten.dk hvor der køre
en velkomstmeddelelse i statuslinien - dog alene til folk der ikke er logget
på. Selvfølgelig kan der argumenteres imod sådan brug af statuslinien, men
det er jo en smagssag, så hold os om dette til det tekniske. Jeg har valgt
ISO-8859-1 globalt, uden at kende konsekvensen, men udelukkende fordi
valideringen stiller krav om et valg.

> Sådan vil det ofte være - men har man først ....

Det er nok specielt det punkt jeg vil angive, at valideringen halter - der
spændes bredt, men ikke dybt, hvilket fremmer konformitet for kreativitet.
Der udstedes forbud uden sammenhængende, ordentlig forklaring. Kunne man
ikke i det aktuelle eksempel have ofre lidt oplysning på sagen? Bare en
simpel angivelse af den forkert angivede karakterkoden ville jo have fortalt
noget om hvad der var galt. I stedet genererede den (for brugeren
uopdagelige) specialkode flere helt uforståelige fejlangivelser. Det mener
jeg ikke er godt nok fra en serviceudbyder, der angivelig er standardsætter
og -kontrollør.

Så er der browser-idiotiet. Jeg er stadig af den opfattelse, at det
sjældendt er hr.massen der benytter alternativer til IE, men når der nu skal
være konkurrance om hvordan man viser den validerede kode, så kunne man dog
i det mindste reagere ens på samme validerede og godkendte kode. Det er
lykkedes at få en enkelt side godkendt:
http://www.skolekammeraten.dk/have.php, men selv denne forholdsvis simple
side vises forskelligt i IE (son den skal) og FF (med fejl i layout).

> ... det jo bare at bruge søg og erstat ...

Jo, men det er jo li'som ikke pointen - havde jeg ikke mine mange års
erfaring i underlige program"standarder", havde jeg aldrig spottet fejlen.

> Det lyder som et tegnsætsproblem - hvis du fx angiver
> utf8, men skriver i latin-1.

Muligt - jeg har aldrig helt rigtigt fattet sammenhængen, men benytter det,
som jeg har fået opfattelsen af er "det normale".

> Lad os se siden - det er meget lettere at
> bedømme et konkret problem.

http://www.skolekammeraten.dk

> Nej - ikke før jeg har set hvad du bruger det til

Yep! - Det var lige det jeg mente )

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen wrote:
> http://www.skolekammeraten.dk/have.php, men selv denne forholdsvis simple
> side vises forskelligt i IE (son den skal) og FF (med fejl i layout).
>

Hvis du ønsker at det skal se bare nogen lunde ens ud i de forskellige
browsere, bliver du nød til at rette op din kode og lave det efter
nutidens standarder.
Din kode på skolekammeraten er lavet som man kodet i det forrige
årtusinde til gamle IE4.
Det er klart at det ser forskelligt ud i de forskellige browser, du
benytter en DOCTYPE som tricker Quirks mode istedet for Standard mode.

Læs mere om DOCTYPE her:
http://www.hintzmann.dk/articles/doctype/

Hvis du vil lære at kode efter nutidens standarder så er HTMLdog et godt
sted at starte.
http://www.htmldog.com/



--
Martin Hintzmann Andersen
http://www.hintzmann.dk/

---

Poul Erik Jensen skrev:

> Det løser ikke problemet med billederne, der gerne skulle
> fylde en hvilkensomhelst skærm/vinduesstørrelse ud.

Det er svært at lave så det bliver pænt. Browsere er ikke specielt
gode til at skalere billeder. Et andet problem ved at anvende
skalering i browseren er følgende:

Hvis man lader browseren skalere billedet op, bliver billedet
hurtigt groft (pixeleret) at se på.

Lader man browseren skalere billedet ned, skal der overføres en
større fil end der egentlig er brug for (filstørrelsen reduceres
markant hvis man skalerer billedet ned i et grafikprogram).

Hvis man vil undgå at browseren kommer til at skalere op (med
efterfølgende visuelt kvalitetstab), er man nødt til at lægge
billedet ud i en størrelse der passer til de største
vinduesstørrelser man vil tage hensyn til. Men det betyder samtidig
at de fleste browsere vil skulle skalere billedet ned - og dermed
vise siden langsommere end de kunne have gjort, hvis billedet havde
været skaleret i et grafikprogram. Specielt vil folk på ældre
maskiner med langsomme netforbindelser få problemer - når de henter
et billede der fx er tilpasset 1600x1200 pixels, og browseren så
skalerer det til 800 pixels.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Poul Erik Jensen skrev i dk.edb.internet.webdesign.clientside

[jeg krydsposter med opfølgning til html-gruppen - hovedparten af
tråden handler ikke længere om javascript]

> Tja, det er jo ikke noget dårligt argument - selvom jeg også i
> det tilfælde foretrækker selv at stille mine præmisser op )

Det kan du fint gøre - såvel i din tekstbehandler (rediger
programmets standardværdier), som på dine websider (lav et css-ark
ud fra dine egne præferencer).

> Det akuelle problem er på forsiden af www.skolekammeraten.dk
> hvor der køre en velkomstmeddelelse i statuslinien

Validatoren finder 44 html-fejl - men så vidt jeg kan se ikke nogen
der handler om danske tegn. En del fejl er (som nr. 2) af typen "an
attribute value must be a literal unless it contains only name
characters". Den fejltype handler om at man skal huske at bruge
anførselstegn om sine attributværdier (fx <hr width="90%"> i stedet
for <hr width=90%>.

Når fejlmeddelelsen her er "vag" - den fortæller jo ikke direkte at
du skal bruge anførselstegn, er det fordi html-standarden tillader
at man undlader anførselstegn i visse tilfælde. I xhtml har man
ikke det problem - her skal attributværdier altid i anførselstegn.
Generelt er det en god ide at vænne sig til at bruge anførselstegn
i alle tilfælde - uanset om man bruger html eller xhtml.

NB: Jeg ser ikke teksten i statuslinjen - en indstilling i min
browser forhindrer den slags tekster i at blive vist.


> Så er der browser-idiotiet. Jeg er stadig af den opfattelse,
> at det sjældendt er hr.massen der benytter alternativer til
> IE, men når der nu skal være konkurrance om hvordan man viser
> den validerede kode, så kunne man dog i det mindste reagere
> ens på samme validerede og godkendte kode.

Det gør browserne også et langt stykke hen ad vejen. Når det
alligevel ikke altid går helt af sig selv, skyldes det typisk to
ting:

- hensyntagen til gamle browsere
- divergerende standardværdier

I mindre grad kan man også støde på forskelle der skyldes konkrete
fejl i de nyere browsere.


> Det er lykkedes at få en enkelt side godkendt:
> http://www.skolekammeraten.dk/have.php, men selv denne
> forholdsvis simple side vises forskelligt i IE (son den skal)
> og FF (med fejl i layout).

Der er flere problemer med den side. Først og fremmest er css-koden
ikke valideret - hvis browserne skal vise det ensartet, skal både
html og css valideres.

Dernæst bruger du flere javascripts angivet som følger:
   <script type="text/javascript" language="JavaScript1.2">
Det kan give problemer at bruge language-parameteren på javascripts
- specielt når man angiver versionsnummer. Nogle browsere skifter
til en ældre javascriptmotor når de møder 1.2-angivelsen, mens
andre kun kan tolke det efter moderne javascriptstandarder (1.5 så
vidt jeg husker).

Indholdet i javascriptene er også uheldigt. Der sniffes efter IE
eller Netscape 6 - men det er meget længe siden at de to store
browsere hed IE og Netscape.

Så er der spørgsmålet om doctypekontakten - hvor siden sætter
quirksmode i stedet for standardmode. Det er normalt også en dårlig
ide hvis man vil have ensartet visning i IE, Firefox og Opera m.fl.

Når man kigger koden igennem (have.php) er der store mængder af
gammel javascriptkode i den. Det er ikke umiddelbart hvad jeg
forstår ved en "simpel side".


> Jo, men det er jo li'som ikke pointen - havde jeg ikke mine
> mange års erfaring i underlige program"standarder", havde jeg
> aldrig spottet fejlen.

Du har fundet gruppen her - den er glimrende hvis man søger hjælp
til den type fejl.

Krydspostet til 2 grupper, opfølgning (FUT) til:
<news:dk.edb.internet.webdesign.html>
Om FUT og X-FUT: <http://www.usenet.dk/ord/lokal.html#fut>

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns96C49BA254488jcdmfdk@gyrosmod.dtext.news.tele.dk...

> [jeg krydsposter med opfølgning til html-gruppen - hovedparten
> af tråden handler ikke længere om javascript]

Nej, jeg stopper lige debatten, for at kunne kapere de mange input og vende
tilbage når jeg har fået tid til at bearbejde dem.

> Dernæst bruger du flere javascripts angivet som følger:
> <script type="text/javascript" language="JavaScript1.2">

Det troede jeg faktisk var nødvendigt - men retter gerne, lige som jeg gerne
retter til rette sprog og DOCTYPE - og kunne måske godt bruge et hint om
det sidste, som jeg ellers var overbevist af valideringen var korrekt.

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Poul Erik Jensen skrev:

>> [jeg krydsposter med opfølgning til html-gruppen -
>> hovedparten af tråden handler ikke længere om javascript]
>
> Nej, jeg stopper lige debatten, for at kunne kapere de mange
> input og vende tilbage når jeg har fået tid til at bearbejde
> dem.

O.k. - men jeg vil så foreslå dig at spørge i html-gruppen, hvis
det ikke er konkrete javascriptspørgsmål du har.


>> Dernæst bruger du flere javascripts angivet som følger:
>> <script type="text/javascript" language="JavaScript1.2">

> Det troede jeg faktisk var nødvendigt - men retter gerne,

Scriptblokke bør angives således:

<script type="text/javascript"> ... </script>.

Type-parameteren er obligatorisk, mens language-parameteren er
forældet.


> DOCTYPE - og kunne
> måske godt bruge et hint om det sidste, som jeg ellers var
> overbevist af valideringen var korrekt.

Den doctype du har anvendt er ikke forkert (den kan som du selv har
fundet ud af godt valideres) - men den er uhensigtsmæssig.

Du kan se forklaringen her:
<http://www.hintzmann.dk/articles/doctype/> (specielt afsnittet
"Den rigtige renderingsmetode"). Vil man bruge html 4.01
transitional og samtidig sætte browserne i standardmode, skal man
bruge en doctype-erklæring med url:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Hej Poul

Dit spørgsmål hører vist snarere hjemme i dk.edb.internet.webdesign, men
her kommer alligevel et svar.

Du kan sagtens style dig ud af det - prøv at sætte
style="display:inline;margin:0px;padding:0xp;" på dit formtag - jeg tror
det virker.

At lave sider, som validerer er vigtigt, da standarden er din garanti
for at hjemmesiden kan læses af mange forskellige browsere og i fremtiden.

At skrive hjemmesider, som ikke validerer, svarer til at skrive tekst i
slang. Om 2 år er der ingen, som fatter, hvad der står, fordi de ikke
kan slå ordene op. På samme måde kan du ikke være sikker på, at en
browser kan læse din side i fremtiden, hvis den ikke overholder standarden.

validation er ikke en spændetrøje - tværtimod :)

Mvh Christian

Poul Erik Jensen wrote:
> Nu har jeg pligtskyldigt forsøgt at validere en enkelt af mine sider - men
> følger man reglerne støder man konstant på forhindringer, der tilsyneladende
> ikke lader sig løse tilfredsstillende.
>
> Det må man ikke - og hvad så?
>
> Et af de problemer jeg er stødt på - og hoppet hen over med den løsning jeg
> kunne finde - er de(t) linieskift der opstår i forbindelse med FORM-tag.
>
> Hidtil har jeg "gemt" disse i tabeltags - men den går jo ikke ;-((
>
> Hvad hulen gør man så?
>
> Jo, man skal bar bruge style siger klåge Åge! - desværre virker dette heller
> ;-((
>
> Så, hvem kan/vil svare på dette teoretiske spørgsmål, der ikke er forbundet
> med noget bestemt, og derfor heller ikke kan sidehenvises.
>
> Hvorfor i alverden laver FORM-tag et linieskift?
> Hvorfor kan FORM ikke nestes med TABLE eller DIV?
>
> Vel, det er der jo en browser der kan - er det så den der er super, erller
> de andre der er dukse?
>
> Ja unskyld - jeg spørger blot.
>