---

Hej...

jeg er ved at lave et site med frameset, men har et mindre
problem... Selv om jeg har fjernet border, så er der en meget
lille kant på en px, som er meget træls.... Hvordan fjerne jeg
den????


¨


--
Danmarks største specialiserede IT jobdatabase
- Udelukkende med IT- og internetrelaterede jobs
- Opret en profil og lad drømmejobbet finde dig
KLIK HER! => http://www.html.dk/job

---

Rasmus Søholm skrev:

> Hej...
>
> jeg er ved at lave et site med frameset, men har et mindre
> problem... Selv om jeg har fjernet border, så er der en meget
> lille kant på en px, som er meget træls.... Hvordan fjerne jeg
> den????

Prøv
<frameset cols="*,*,*" border="0" framespacing="0" frameborder="no">

Olav

---

"Rasmus Søholm" <tykmin@pastil.dk> skrev i en meddelelse

> jeg er ved at lave et site med frameset, men har et mindre
> problem... Selv om jeg har fjernet border, så er der en meget
> lille kant på en px, som er meget træls.... Hvordan fjerne jeg
> den????

Man kan godt fjerne den sidste kant, men det kan ikke gøres i Ren CSS så den
valideres i W3C standarderne, da der er en lille fejl ved det.
Hvis man dog gerne vil have den kant væk må koden være...

border="0" i <frameset>
og
frameborder="0" i <frame>

Så er borderen væk i alle browsere.

---

Fair nok nu har jeg fundet ud af det... Det var bare "framespacing" jeg havde
glemt at tage højte for.....

--
Danmarks største specialiserede IT jobdatabase
- Udelukkende med IT- og internetrelaterede jobs
- Opret en profil og lad drømmejobbet finde dig
KLIK HER! => http://www.html.dk/job

---

Steen wrote:

> Man kan godt fjerne den sidste kant, men det kan ikke gøres i Ren
> CSS så den valideres i W3C standarderne, da der er en lille fejl
> ved det. Hvis man dog gerne vil have den kant væk må koden være...

Alternativt kan man modificere DTD'en for Frameset og tilføje border-
attributtet på frameset-elementet. Dermed kan man fjerne kanten på
legal vis.

--
Martin

---

Davs du
Martin Poulsen <pi10y3002@sneakemail.com> skrev bla:
> Alternativt kan man modificere DTD'en for Frameset og tilføje border-
> attributtet på frameset-elementet. Dermed kan man fjerne kanten på
> legal vis.

Lad os se et eks

--
Mvh. John
www.johns-web.dk / www.jp-web.dk
www.web-templates.dk
Teamwork sharpening the skills!!

---

jopa wrote:

> Davs du
> Martin Poulsen <pi10y3002@sneakemail.com> skrev bla:
>> Alternativt kan man modificere DTD'en for Frameset og tilføje
>> border- attributtet på frameset-elementet. Dermed kan man fjerne
>> kanten på legal vis.
>
> Lad os se et eks

http://users.cybercity.dk/~dsl85798/index.html

--
Martin

---

Davs du
Martin Poulsen <pi10y3002@sneakemail.com> skrev bla:
> jopa wrote:
> http://users.cybercity.dk/~dsl85798/index.html

Fint så er der jo håb for frames freaksene

--
Mvh. John
www.johns-web.dk / www.jp-web.dk
www.web-templates.dk
Teamwork sharpening the skills!!

---

Martin Poulsen <pi10y3002@sneakemail.com> skrev:

> Alternativt kan man modificere DTD'en for Frameset og tilføje border-
> attributtet på frameset-elementet. Dermed kan man fjerne kanten på
> legal vis.

Det er et skråplan at komme ud på - alle kender "standarden" og den
bør følges.

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

---

Allan Vebel wrote:

> Martin Poulsen <pi10y3002@sneakemail.com> skrev:
>
>> Alternativt kan man modificere DTD'en for Frameset og tilføje
>> border- attributtet på frameset-elementet. Dermed kan man fjerne
>> kanten på legal vis.
>
> Det er et skråplan at komme ud på - alle kender "standarden" og
> den bør følges.

Generelt er jeg enig i, at det er bedst at vi har en fælles standard.
Det ændrer bare ikke på det forhold, at de (W3C) ikke har eneret på at
lave dem.

Hvis det ligger sådan, at man for en hver pris, skal ha' fjernet det
tomrum, der er mellem rammerne, så er det bedre at definere det i
DTD'en, således at dokumentet overholder den standard man sætter for
det, end at man lader det bruge ikke-definerede attributter. Set i det
perspektiv mener jeg ikke det er skråplan.

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> writes:

> Hvis det ligger sådan, at man for en hver pris, skal ha' fjernet det
> tomrum, der er mellem rammerne,

Så brug en HTML-version der tillader det.
(Eller, hvis du virkelig mener "for enhver pris", så tag W3C-bestyrelsen
som gidsler indtil det bliver indført :)).

> så er det bedre at definere det i DTD'en, således at dokumentet
> overholder den standard

Her bruger du en definition af standard som jeg kender.
Der er to typer standarder: de fakto og de jura. W3C's standarder
er de jura. Microsofts quirks mode er de fakto standard. Din DTD
er en variant, men ikke en "standard" i nogen meningsfuld betydning
af ordet.

> man sætter for det, end at man lader det bruge ikke-definerede
> attributter.

Men du bruger jo ikke-definerde attributter.

Du laver en tilføjelse til en DTD. Det er helt lovligt, det
giver en ny DTD for et nyt sprog.

Du bruger den DTD sammen med en DOCTYPE der ikke passer (som jeg
forstår det). Altså
<!DOCTYPE html PUBLIC "-//W3C//XHTML 1.0//EN" "<din DTD>">
Det er forkert, den DTD du giver passer ikke til den dokumenttype
du angiver. Du kunne lige så godt (eller bedre) skrive
<!DOCTYPE html PUBLIC "-//MigSelv//SuperHTML 1.0//EN" "<din DTD>">

Hvis du siger at dit dokument er XHTML 1.0, men med din DTD, så
lever du højt på at browserne vælger at forstå den tilføjede attribut,
selvom den ikke er defineret i XHTML 1.0. Du har tilføjet en definition
i *syntaksen*, men du har ikke tilføjet en definition af betydningen
af den "nye" attribut. Du er heldig, og browserne falder tilbage
på den mening den ikke-definerede attribut har i HTML.

> Set i det perspektiv mener jeg ikke det er skråplan.

Nej, det er allerede faldet ud over kanten. :)
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen <lrn@hotpop.com> skrev :

>> Hvis det ligger sådan, at man for en hver pris, skal ha' fjernet det
>> tomrum, der er mellem rammerne,
>
>Så brug en HTML-version der tillader det.

Eksisterer ikke, det er kun frameborder=0 angivet i <frameset>
der fjerner borderen helt og det er ikke tilladt i nogen doctype.

--
Knud - http://home13.inet.tele.dk/smedpark/
Når der svares på et indlæg, svar venligst under det citerede og
skær venligst det væk, du ikke svarer på, ellers ryger du i killfiltret.
Svar kun i nyhedsgruppen - tak! E-mails besvares ikke.

---

Knud Gert Ellentoft <knudgert@mail.tele.dk> writes:

> Eksisterer ikke, det er kun frameborder=0 angivet i <frameset>
> der fjerner borderen helt og det er ikke tilladt i nogen doctype.

Den her skulle efter sigende have frameborder-attributten på frameset:
"-//Microsoft//DTD Internet Explorer 3.0 HTML//EN"
(DTD: <URL:http://www.algonet.se/~eva/ref/html/dtd/ie3dtd.html>)
Den mangler til gengæld en masse andet, men "for enhver pris" etc. :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Knud Gert Ellentoft wrote:

> Lasse Reichstein Nielsen <lrn@hotpop.com> skrev :
>
>>> Hvis det ligger sådan, at man for en hver pris, skal ha' fjernet
>>> det tomrum, der er mellem rammerne,
>>
>>Så brug en HTML-version der tillader det.
>
> Eksisterer ikke, det er kun frameborder=0 angivet i <frameset>
> der fjerner borderen helt og det er ikke tilladt i nogen doctype.

En lille korrektion - frameborder er angivet som attribut for frameset-
elementet. Det er border der ikke er. frameborder fjerner rammen
visuelt, men den efterlader et tomrum på en håndfuld pixels, hvor
rammen ellers skulle ha' været. border-attributtet fjerner dette tomrum
helt.

--
Martin

---

Lasse Reichstein Nielsen wrote:

> Så brug en HTML-version der tillader det.
> (Eller, hvis du virkelig mener "for enhver pris", så tag
> W3C-bestyrelsen som gidsler indtil det bliver indført :)).

Problemet er, at det ikke findes. border-attributtet er ikke en del
af den specifikation som W3C har lavet.

> Her bruger du en definition af standard som jeg kender.
> Der er to typer standarder: de fakto og de jura. W3C's standarder
> er de jura. Microsofts quirks mode er de fakto standard. Din DTD
> er en variant, men ikke en "standard" i nogen meningsfuld
> betydning af ordet.

Ikke enig - min DTD kan være lige så god som W3C's. Den er dog ikke
en standard i den henseende, at den er bredt kendt, understøttet,
etc.

>> man sætter for det, end at man lader det bruge ikke-definerede
>> attributter.
>
> Men du bruger jo ikke-definerde attributter.

Nej, de er definerede i DTD'en.

> Du laver en tilføjelse til en DTD. Det er helt lovligt, det
> giver en ny DTD for et nyt sprog.

Ja.

> Du bruger den DTD sammen med en DOCTYPE der ikke passer (som jeg
> forstår det). Altså
> <!DOCTYPE html PUBLIC "-//W3C//XHTML 1.0//EN" "<din DTD>">
> Det er forkert, den DTD du giver passer ikke til den dokumenttype
> du angiver. Du kunne lige så godt (eller bedre) skrive
> <!DOCTYPE html PUBLIC "-//MigSelv//SuperHTML 1.0//EN" "<din
> DTD>">

Så må du hellere kigge igen - jeg bruger min egen DOCTYPE-erklæring:

<!DOCTYPE html PUBLIC "-//RandomOrg//DTD XHTML 1.0 Extended
Frameset//EN"
"http://users.cybercity.dk/~dsl85798/doctype/xhtml1-extended-frameset
..dtd">

Ellers ville den jo netop ikke validere.

> Hvis du siger at dit dokument er XHTML 1.0, men med din DTD, så
> lever du højt på at browserne vælger at forstå den tilføjede
> attribut, selvom den ikke er defineret i XHTML 1.0.

Jeg siger ikke at mit dokumentet er XHTML 1.0. (Folk har en underlig
tendens til at hælde ord i min mund. ;))

> Du har
> tilføjet en definition i *syntaksen*, men du har ikke tilføjet en
> definition af betydningen af den "nye" attribut.

Ja, selvfølgelig har jeg tilføjet en definition i syntaxen. Jeg er
udemærket klar over, at den ikke er en "standard-attribut" i den
hensende, som nævnt ovenfor, at den er bredt kendt, understøttet,
etc.

> Du er heldig, og
> browserne falder tilbage på den mening den ikke-definerede
> attribut har i HTML.


Heldig? Den må du uddybe.


> Nej, det er allerede faldet ud over kanten. :)

Overhovedet ikke. :)

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> wrote in
news:Xns934961E601DC9pi10y3002@130.225.247.90:

> Ikke enig - min DTD kan være lige så god som W3C's. Den er dog ikke
> en standard i den henseende, at den er bredt kendt, understøttet,
> etc.

Det var da noget af en selvmodsigelse. Din DTD vil aldrig være lige så god
netop fordi den aldrig vil blive bredt understøttet.

--
Andreas
<http://www.solitude.dk>

---

Andreas Haugstrup Pedersen wrote:

> Martin Poulsen <pi10y3002@sneakemail.com> wrote in
> news:Xns934961E601DC9pi10y3002@130.225.247.90:
>
>> Ikke enig - min DTD kan være lige så god som W3C's. Den er dog
>> ikke en standard i den henseende, at den er bredt kendt,
>> understøttet, etc.
>
> Det var da noget af en selvmodsigelse. Din DTD vil aldrig være
> lige så god netop fordi den aldrig vil blive bredt understøttet.

Rent "DTD'sk" er den ligeså god som W3C's (den er jo blot en
modificeret udgave, af deres allerede eksisterende). Men den er ikke
ligeså "god" rent udbredelsesmæssigt. Kan ikke se selvmodsigelsen.

--
Martin

---

"Martin Poulsen" <pi10y3002@sneakemail.com> skrev
> Ikke enig - min DTD kan være lige så god som W3C's. Den er dog
> ikke en standard i den henseende, at den er bredt kendt,
> understøttet, etc.
>
> Rent "DTD'sk" er den ligeså god som W3C's (den er jo blot en
> modificeret udgave, af deres allerede eksisterende). Men den er ikke
> ligeså "god" rent udbredelsesmæssigt. Kan ikke se selvmodsigelsen.

Hvis vi allesammen går rundt og opfinder vores egne standarder, bare for at
kunne få vores håbløse sider til at validere, i stedet for at overholde den
standard, som W3C anbefaler, hvad skal de stakkels browserprogrammører så
rette sig efter.

Det ender da med at blive et stort uoverskueligt rod. Så vil det da være
mere hensigtsmæssigt at læne sig så kraftigt op ad de vise herrer i W3c, så
at de muliggør fjernelse af synlig border i frameset - efter en fælles
standard.

Som Lasse R antydede i en anden tråd om samme emne: Martin, du er så langt
ude over kanten, at du ikke længere har kontakt til skråplanet.

Du direkte modarbejder mange menneskers forsøg på at etablere én fælles
standard, som alle browsere forstår og som alle Web-designere kan (lære at)
finde ud af at skrive til.

--
Med venlig hilsen
Erik Ginnerskov - erik snabela ginnerskov dot dk
http://www.hjemmesideskolen.dk - http://www.html-faq.dk
http://hjem.get2net.dk/sorgin

---

Erik Ginnerskov wrote:

> Hvis vi allesammen går rundt og opfinder vores egne standarder,
> bare for at kunne få vores håbløse sider til at validere, i stedet
> for at overholde den standard, som W3C anbefaler, hvad skal de
> stakkels browserprogrammører så rette sig efter.

Generelt enig.

> Det ender da med at blive et stort uoverskueligt rod. Så vil det
> da være mere hensigtsmæssigt at læne sig så kraftigt op ad de vise
> herrer i W3c, så at de muliggør fjernelse af synlig border i
> frameset - efter en fælles standard.

Den forstod jeg ikke helt. Kan du uddybe?

> Som Lasse R antydede i en anden tråd om samme emne: Martin, du er
> så langt ude over kanten, at du ikke længere har kontakt til
> skråplanet.

Ifald du mener det, så er du så langt ude over kanten, at du ikke
aner hvad der tales om - eller i hvert fald ikke har forstået
princippet i det, jeg har lavet. (Eller at jeg ikke har forklaret
mine hensigter godt nok.) ;)

> Du direkte modarbejder mange menneskers forsøg på at etablere én
> fælles standard, som alle browsere forstår og som alle
> Web-designere kan (lære at) finde ud af at skrive til.

Nej, det gør jeg absolut ikke. Jeg har stor respekt for det arbejde
W3C udfører, og bakker op om det til enhver tid.

Det der er problemet er, at du ikke med valid kode efter W3C's
specifikationer, kan fjerne det tomrum mellem rammerne som
frameborder="0" vil lave. Løsningen på det ser jeg som en enten-
eller-situation: overhold de specifikationer du sætter for
dokumentet, eller lad helt være. Det giver efter min mening et par
muligheder:

1. Man overholder specifikationen som W3C har lavet, og må leve med
tomrummet mellem rammerne.

2. Man erklærer en W3C-doctype, men benytter alligevel border-
attributtet til at fjerne tomrummet med, i strid med DTD'en.

3. Man lader være med at sætte en doctype, sætter browseren i quirks
mode, og skriver HTML-koden efter forgodtbefindende.

4. Man laver sin egen DTD (/modificerer en anden), således at border-
attributtet bliver en del af definitionen for det enkelte dokument,
og man kan fjerne tomrummet på legal vis.

Jeg vil kun kunne accepterer 2 af ovennævnte muligheder, og det er 1
og 4. Mulighed nummer 2 er vanvittig - hvorfor bruge tid på at
erklære en doctpype, for så senere at bryde den? Nummer 3 sætter
browseren i quirks mode, og så har du ikke længere en "standard" at
holde dig til.

Nummer 4 giver muligheden for, at fjerne tomrummet på helt legal vis,
da man overholder den doctype, man har erklæret for dokumentet. Der
er i begge tråde om dette emne, blevet svaret at ikke kunne lade sig
gøre med validerbar kode. Jeg har blot "bevist", at det kan lade sig
gøre.

Jeg kan kun se det som et skråplan, hvis folk misbruger det som et
skalkesjul for, at tilføje attributter, elementer m.m til DTD'en for
at kunne bruge nogle koder som de enkelte browserfirmaer har opfundet
af dem selv. Det specielle i denne situation er, at border-
attributtet på frameset-elementet er defineret i de "3
hovedbrowsere" (Mozilla, Internet Explorer og Opera), og at man ikke
kan fjerne tomrummet ad andre veje. Det er ikke et forsøg på at
underminere W3C's arbejde - det er forsøg på, at fjerne tomrummet på
legal vis.

--
Marti

---

"Martin Poulsen" <pi10y3002@sneakemail.com> skrev
> Erik Ginnerskov wrote:
>
> > Det ender da med at blive et stort uoverskueligt rod. Så vil det
> > da være mere hensigtsmæssigt at læne sig så kraftigt op ad de vise
> > herrer i W3c, så at de muliggør fjernelse af synlig border i
> > frameset - efter en fælles standard.
>
> Den forstod jeg ikke helt. Kan du uddybe?

Det er W3C, der har vedtaget, at frameborder=0 sat i frameset ikke er valid
kode. Men det er den eneste måde at fjerne frameborder på. Altså m d'herrer
bringes til at forstå, at denne kode bør være valid kode, indtil browserne
forstår en anden måde at fjerne frameborder på.

> > Som Lasse R antydede i en anden tråd om samme emne: Martin, du er
> > så langt ude over kanten, at du ikke længere har kontakt til
> > skråplanet.
>
> Ifald du mener det, så er du så langt ude over kanten, at du ikke
> aner hvad der tales om - eller i hvert fald ikke har forstået
> princippet i det, jeg har lavet. (Eller at jeg ikke har forklaret
> mine hensigter godt nok.) ;)

Du har for så vidt forklaret dine hensigter godt nok, men når så i din dtd
kalder det, du har lavet for xhtml 1.0 extended og kalder din side for valid
xhtml 1.0., så er du helt ved siden af.

Xhtml 1.0 er en standard lavet af W3C. Den udvidelse du laver fratager dig
retten til at kalde din dtd for xhtml 1.0 med eller uden tilføjelsen
extended.

Og din side består af tohundrede linjer doctypedefinitioner, men jeg kunne
overhovedet ikke få øje på noget som helst, der berettiger, at du kalder
siden noget med html. Og her taler jeg ikke om kildekode, den har jeg
muligvis ikke set. Jeg har taget en viewsource fra browseren, dvs. efter at
din kildekode evt. har været en tur gennem en servers fortolker.

> Det der er problemet er, at du ikke med valid kode efter W3C's
> specifikationer, kan fjerne det tomrum mellem rammerne som
> frameborder="0" vil lave. Løsningen på det ser jeg som en enten-
> eller-situation: overhold de specifikationer du sætter for
> dokumentet, eller lad helt være. Det giver efter min mening et par
> muligheder:
>
> 1. Man overholder specifikationen som W3C har lavet, og må leve med
> tomrummet mellem rammerne.
>
> 2. Man erklærer en W3C-doctype, men benytter alligevel border-
> attributtet til at fjerne tomrummet med, i strid med DTD'en.
>
> 3. Man lader være med at sætte en doctype, sætter browseren i quirks
> mode, og skriver HTML-koden efter forgodtbefindende.
>
> 4. Man laver sin egen DTD (/modificerer en anden), således at border-
> attributtet bliver en del af definitionen for det enkelte dokument,
> og man kan fjerne tomrummet på legal vis.

Eller en helt femte mulighed, som jeg praktiserede, indtil jeg for et par
måneder siden ophørte med at bruge frames.
Design siderne, så den hvide kant mellem frames glider i et med siden
baggrund. Det er en valid metode efter W3C's definitioner.

--
Med venlig hilsen
Erik Ginnerskov - erik snabela ginnerskov dot dk
http://www.hjemmesideskolen.dk - http://www.html-faq.dk
http://hjem.get2net.dk/sorgin

---

"Erik Ginnerskov" <egin@SPAMKILLoncable.dk> skrev

>
> Eller en helt femte mulighed, som jeg praktiserede, indtil jeg for et par
> måneder siden ophørte med at bruge frames.
> Design siderne, så den hvide kant mellem frames glider i et med siden
> baggrund. Det er en valid metode efter W3C's definitioner.

Eller en sjette mulighed: Da det blot drejer sig om et frameset, altså en
ramme, hvori valide sider kan vises, så skid på, om framesettet kan
validere. Browserne forstår frameset=0 sat på frameset-definitionen og
fortolker attributten som ønsket.

--
Med venlig hilsen
Erik Ginnerskov - erik snabela ginnerskov dot dk
http://www.hjemmesideskolen.dk - http://www.html-faq.dk
http://hjem.get2net.dk/sorgin

---

Erik Ginnerskov wrote:

> Eller en sjette mulighed: Da det blot drejer sig om et frameset,
> altså en ramme, hvori valide sider kan vises, så skid på, om
> framesettet kan validere. Browserne forstår frameset=0 sat på
> frameset-definitionen og fortolker attributten som ønsket.

Det er, hvis jeg har forstået det ret, den mulighed jeg kalder for
nummer 2.

--
Martin

---

Erik Ginnerskov wrote:

> Det er W3C, der har vedtaget, at frameborder=0 sat i frameset ikke
> er valid kode. Men det er den eneste måde at fjerne frameborder
> på. Altså m d'herrer bringes til at forstå, at denne kode bør være
> valid kode, indtil browserne forstår en anden måde at fjerne
> frameborder på.

Det er så ikke frameborder, men border-attributtet der ikke er en del
af standarden. Det er for så vidt ligemeget - jeg forstår din pointe.

> Du har for så vidt forklaret dine hensigter godt nok, men når så i
> din dtd kalder det, du har lavet for xhtml 1.0 extended og kalder
> din side for valid xhtml 1.0., så er du helt ved siden af.

Endnu en - hvor har jeg påstået det er valid XHTML 1.0? W3C's
validator udtaler sig således:

This Page Is Valid -//RandomOrg//DTD XHTML 1.0 Extended Frameset//EN!

Hvis jeg påstår det er valid XHTML 1.0, taler jeg imod validatoren.

> Xhtml 1.0 er en standard lavet af W3C. Den udvidelse du laver
> fratager dig retten til at kalde din dtd for xhtml 1.0 med eller
> uden tilføjelsen extended.

Jeg kan ikke kalde det for valid XHTML 1.0. Jeg kan kalde det for
valid XHTML 1.0 Extended Frameset. Hvis det er problem hvad jeg
kalder det, så skal jeg nok kalde det KrydsHåTeEmEl 0.1 Udvidet
Rammesæt.

> Og din side består af tohundrede linjer doctypedefinitioner, men
> jeg kunne overhovedet ikke få øje på noget som helst, der
> berettiger, at du kalder siden noget med html.

Hvad berettiger så W3C til at kalde deres specifikationer for HTML?
Hvis W3C har eneret på at kalde noget for HTML, så skal jeg nok finde
på et andet navn, for så er det jura, og ikke "webdesign".

> Og her taler jeg
> ikke om kildekode, den har jeg muligvis ikke set. Jeg har taget en
> viewsource fra browseren, dvs. efter at din kildekode evt. har
> været en tur gennem en servers fortolker.

Servers fortolker? Den skal jeg også lige ha' en uddybning af. :)

> Eller en helt femte mulighed, som jeg praktiserede, indtil jeg for
> et par måneder siden ophørte med at bruge frames.
> Design siderne, så den hvide kant mellem frames glider i et med
> siden baggrund. Det er en valid metode efter W3C's definitioner.

Jaeh, den ligger sig tæt op ad punkt 1.

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> wrote in
news:Xns93496B536AA97pi10y3002@130.225.247.90:

> Andreas Haugstrup Pedersen wrote:
>
>> Martin Poulsen <pi10y3002@sneakemail.com> wrote in
>> news:Xns934961E601DC9pi10y3002@130.225.247.90:
>>
>>> Ikke enig - min DTD kan være lige så god som W3C's. Den er dog
>>> ikke en standard i den henseende, at den er bredt kendt,
>>> understøttet, etc.
>>
>> Det var da noget af en selvmodsigelse. Din DTD vil aldrig være lige så
>> god netop fordi den aldrig vil blive bredt understøttet.
>
> Rent "DTD'sk" er den ligeså god som W3C's (den er jo blot en
> modificeret udgave, af deres allerede eksisterende). Men den er ikke
> ligeså "god" rent udbredelsesmæssigt. Kan ikke se selvmodsigelsen.

Rent teknisk kan den være fin fin, men i og med den ikke er understøttet
eller anerkendt er den ubrugelig.

--
Andreas
<http://www.solitude.dk>

---

Andreas Haugstrup Pedersen wrote:

> Rent teknisk kan den være fin fin, men i og med den ikke er
> understøttet eller anerkendt er den ubrugelig.

Jeg har nok formuleret mig uheldigt. Den border-attribut, jeg har
tilføjet, er understøttet i de 3 "hovedbrowsere". Dermed er den ikke
ubrugelig (i hvert fald ikke i de 3 browsere - og måske flere). Om den
er anerkendt eller ej, kan så vidt være ligemeget.

Som Jens Gyldenkærne fastslår andetsteds, så bruges doctype (også så
vidt jeg ved) i dag kun til at sætte browseren i 'standard mode'.

Læs evt.:
Xns93497EB0812FBjcdmfdk@gyrosmod.dtext.news.tele.dk
Xns9349811508969pi10y3002@130.225.247.90

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> wrote in
news:Xns93498FB4E2B90pi10y3002@130.225.247.90:

> Andreas Haugstrup Pedersen wrote:
>
>> Rent teknisk kan den være fin fin, men i og med den ikke er
>> understøttet eller anerkendt er den ubrugelig.
>
> Jeg har nok formuleret mig uheldigt. Den border-attribut, jeg har
> tilføjet, er understøttet i de 3 "hovedbrowsere". Dermed er den ikke
> ubrugelig (i hvert fald ikke i de 3 browsere - og måske flere). Om den
> er anerkendt eller ej, kan så vidt være ligemeget.
>
> Som Jens Gyldenkærne fastslår andetsteds, så bruges doctype (også så
> vidt jeg ved) i dag kun til at sætte browseren i 'standard mode'.

Doctype bruges til at angive hvilken version af HTML du bruger i det
aktuelle dokument. Når du ikke bruger en af de af W3C angivne DTD'er kan
browseren i bedste fald gætte på.. ukendt. Browseren har ikke en chance for
at vide hvad det er du skriver. Hvis du er heldig hopper browseren i en
eller anden quirks-mode fordi du ikke har angivet en gyldig HTML DTD.

At dine tre browsere fjerner border er mere held end forstand. Du har ingen
mulighed for at vide om det ændrer sig med den næste browserudgivelse.

--
Andreas
<http://www.solitude.dk>

---

Andreas Haugstrup Pedersen wrote:

> Doctype bruges til at angive hvilken version af HTML du bruger i
> det aktuelle dokument. Når du ikke bruger en af de af W3C angivne
> DTD'er kan browseren i bedste fald gætte på.. ukendt. Browseren
> har ikke en chance for at vide hvad det er du skriver. Hvis du er
> heldig hopper browseren i en eller anden quirks-mode fordi du ikke
> har angivet en gyldig HTML DTD.

Du bliver ved med at tro, at kun W3C må lave doctypes, og at disse
helt eksplicit definerer hvordan et dokument formateres. Doctypen er
skrevet i SGML, der bruges til at definere syntaxen for det dokument,
doctypen bruges i. Gyldig HTML DTD? Det er ikke W3C der gør en DTD
gyldig. Det er DTD'en der bestemmer om den kode du har skrevet i dit
dokument er gyldig jævnfør de regler DTD'en fastsætter.

> At dine tre browsere fjerner border er mere held end forstand. Du
> har ingen mulighed for at vide om det ændrer sig med den næste
> browserudgivelse.

Det har intet med hverken held eller forstand at gøre. border er i de
givne browsere, defineret til at fjerne tomrummet mellem rammerne.
Jeg har så lavet en DTD, der gør det gyldigt at bruge border-
attributtet.

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> wrote in
news:Xns93499490FFE9Fpi10y3002@130.225.247.90:

> Du bliver ved med at tro, at kun W3C må lave doctypes, og at disse
> helt eksplicit definerer hvordan et dokument formateres.

Nej, men det er kun W3C der laver HTML doctypes. Ellers er der tale om en
XML doctype.

> Doctypen er skrevet i SGML, der bruges til at definere syntaxen for det
> dokument, doctypen bruges i.

Det er jo der hele problemet er. Din syntaks kan være hel fin (og det er
den sikkert siden du selv har skrevet DTD'en), men den fortæller ingenting
om hvordan browseren skal rendere et givent element.

> Gyldig HTML DTD? Det er ikke W3C der går en DTD
> gyldig. Det er DTD'en der bestemmer om den kode du har skrevet i dit
> dokument er gyldig jævnfør de regler DTD'en fastsætter.

Det er W3C der varetager alle gyldige HTML DTD'er. Du kan skrive alle dem
du har lyst til, men det bliver aldrig HTML. Derfor skal du ikke udnytte
browsernes svagheder og lade som om det er HTML. Server en text/xml
content-type og et ordenligt stylesheet i stedet.

--
Andreas
<http://www.solitude.dk>

---

Andreas Haugstrup Pedersen wrote:

> Nej, men det er kun W3C der laver HTML doctypes. Ellers er der
> tale om en XML doctype.

Den må du simpelthen underbygge med noget dokumentation.

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> wrote in
news:Xns93499E5CD2BEApi10y3002@130.225.247.90:

> Andreas Haugstrup Pedersen wrote:
>
>> Nej, men det er kun W3C der laver HTML doctypes. Ellers er der tale om
>> en XML doctype.
>
> Den må du simpelthen underbygge med noget dokumentation.

HTML er defineret som de specifikationer der er udgivet af W3C og derfor er
det naturligvis kun W3C der kan udgive nye HTML-versioner.

Du kan jo heller ikke tage et stykke Open Source software som RedHat Linux
v. 8, ændre nogle ting og så kalde det RedHat Linux v. 9. Du kan kalde det
Martin Poulsens Linux baseret på RedHat Linux, men det vil aldrig være
RedHat Linux.

--
Andreas
<http://www.solitude.dk>

---

Andreas Haugstrup Pedersen wrote:

> HTML er defineret som de specifikationer der er udgivet af W3C og
> derfor er det naturligvis kun W3C der kan udgive nye
> HTML-versioner.

Du må finde den definition.

--
Martin

---

Andreas Haugstrup Pedersen <usenet@solitude.dk> writes:

> HTML er defineret som de specifikationer der er udgivet af W3C og derfor er
> det naturligvis kun W3C der kan udgive nye HTML-versioner.

W3C udgiver ikke nye HTML-versioner. De udgiver XHTML i stedet, som jo er XML.
ISO har udgivet en "HTML"-definition, og jeg har ikke hørt nogen sige at den
ikke må kaldes HTML. Altså: Dokumenter venligst at kun definitioner fra W3C
kan kaldes HTML.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen <lrn@hotpop.com> wrote in
news:adfjjvzk.fsf@hotpop.com:

> Andreas Haugstrup Pedersen <usenet@solitude.dk> writes:
>
>> HTML er defineret som de specifikationer der er udgivet af W3C og
>> derfor er det naturligvis kun W3C der kan udgive nye HTML-versioner.
>
> W3C udgiver ikke nye HTML-versioner. De udgiver XHTML i stedet, som jo
> er XML. ISO har udgivet en "HTML"-definition, og jeg har ikke hørt
> nogen sige at den ikke må kaldes HTML. Altså: Dokumenter venligst at
> kun definitioner fra W3C kan kaldes HTML.

XHTML er stadig HTML bare reformuleret så det overholder XML-
specifikationerne (som i øvrigt også er udgivet af W3C).

ISO's HTML er identisk med en af de gamle HTML versioner fra W3C så det er
ret ligemeget. Jeg vil gå ud fra at der er tale om hvad du kalder en de
facto standard. Det giver giver ikke mening at udgive din egen HTML 4. Du
mister du hele pointen i at have et standardiserende organ hvis navnet for
standarden frit benyttes af enhver person til både dit og dat.

--
Andreas
<http://www.solitude.dk>

---

Andreas Haugstrup Pedersen wrote:

> XHTML er stadig HTML bare reformuleret så det overholder XML-
> specifikationerne (som i øvrigt også er udgivet af W3C).
>
> ISO's HTML er identisk med en af de gamle HTML versioner fra W3C
> så det er ret ligemeget. Jeg vil gå ud fra at der er tale om hvad
> du kalder en de facto standard. Det giver giver ikke mening at
> udgive din egen HTML 4. Du mister du hele pointen i at have et
> standardiserende organ hvis navnet for standarden frit benyttes af
> enhver person til både dit og dat.

Altså er det en personlig holdning, at man ikke bør kunne kalde andet
for HTML end det W3C laver. Jeg forventer, at du trækker din påstande
tilbage i de andre tråde.

http://www.w3.org/MarkUp/
Den nævner bl.a. nogle af forskellighederne i ISO HTML - så identisk
er de ikke.

http://www.htmlhelp.com/design/dtd/
"In the context of the WWW, a Document Type Definition (DTD) is an
SGML document that defines a formal, machine-readable standard for
HTML."

Den nævner i øvrigt også at IETF har lavet en DTD.

--
Martin

---

Andreas Haugstrup Pedersen <usenet@solitude.dk> skrev:

> Det var da noget af en selvmodsigelse. Din DTD vil aldrig være lige
> så god netop fordi den aldrig vil blive bredt understøttet.

Det er netop derfor jeg kalder det et skråplan, men den eneste der
ikke forstår det er Martin - han laver bare sine egne regler, hvis han
ikke lige kan få det til at fungere med de eksisterende

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

---

Allan Vebel wrote:

> Det er netop derfor jeg kalder det et skråplan, men den eneste der
> ikke forstår det er Martin - han laver bare sine egne regler, hvis
> han ikke lige kan få det til at fungere med de eksisterende

Utroligt at du udtaler dig, når du ikke har forstået et klap af, hvad
det handler om.

Læs venligst følgende:
Xns9349811508969pi10y3002@130.225.247.90
Xns93497EB0812FBjcdmfdk@gyrosmod.dtext.news.tele.dk

--
Martin

---

Martin Poulsen <pi10y3002@sneakemail.com> skrev:

> Utroligt at du udtaler dig, når du ikke har forstået et klap af, hvad
> det handler om.

Jeg ved godt hvad det handler om - og mener fortsat at det er et
skråplan at lave sine egne regler, bare for at man ikke kan få en
bestemt funktion til at validere.

Der er jo en årsag til at denne funktion er pillet ud af standarden,
og det bør du respektere - frames er en uddøende race.

Jeg ville hellere lave et design helt uden frames, end at ændre på
dtd'en for at få det til at validere - det er en stakket frist.

> Utroligt at du udtaler dig

Jeg har trådt lidt i dine sår og har drillet dig lidt, men sådan er jeg
bare - det håber jeg at du forstår - jeg mener ikke noget ondt med
det. Jeg udtaler mig når jeg har noget at udtale

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

---

Martin Poulsen <pi10y3002@sneakemail.com> writes:

> Ikke enig - min DTD kan være lige så god som W3C's. Den er dog ikke
> en standard i den henseende, at den er bredt kendt, understøttet,
> etc.

Den er ikke standard fordi den er defineret af en standard-definerende
organisation (de jura) eller er bredt udbredt (de fakto). FOr mig betyder
det at den slet ikke er en standard. Det er dog blot et semantisk problem,
fordi vi vist ikke er enige om hvad "standard" dækker over.

> Så må du hellere kigge igen - jeg bruger min egen DOCTYPE-erklæring:
>
> <!DOCTYPE html PUBLIC "-//RandomOrg//DTD XHTML 1.0 Extended
> Frameset//EN"
> "http://users.cybercity.dk/~dsl85798/doctype/xhtml1-extended-frameset
> .dtd">

Ack. Min fejl, jeg gik ikke langt nok tilbage og tjekkede, men stolede
på det jeg havde læst i tråden. Godt nok så!

> > Du er heldig, og browserne falder tilbage på den mening den
> > ikke-definerede attribut har i HTML.

> Heldig? Den må du uddybe.

Hvis du tilføjede en ny attribut i DTD'en der hed "fnullergøj", så
ville du kunne skrive "udvidet HTML" med den attribut. Browseren
har blot ingen chance for at vide hvad du mener, og ignorerer derfor
attributten.

Du tilføjer en ny attribut i DTD'en der hedder "border", så du kan
skrive "udvidet HTML" med den attribut. Du har ikke fortalt browseren
hvad border betyder, og den kunne godt tillade sig, ud fra at den ikke
kender dokumenttypen, at ignorere attributten (den kunne faktisk
ignorere alt om dokumentet ud over at det er et XML-dokument). Det gør
den ikke, den *gætter* på at attributten betyder det samme som i en
dokumenttype den forstår.

Derfor er du "heldig" at browserne er så tilgivende over for folk der
ikke kan finde ud af at skrive en rigtigt dokumenttype, og derfor også
hjælper dig, der skriver en dokumenttype som browseren ikke forstår.

Det skal også nævnes, at CSS-standarden siger om attributter der
påvirker udseendet af koden ("non-CSS presentational hints"):

For XHTML and other languages written in XML, no attribute should be
considered presentational. The styling of elements and
non-presentational attributes should be handled in the user agent
stylesheet.

<URL:http://www.w3.org/TR/CSS21/cascade.html#q12>. Derfor hjælper
det kun at tilføje en "border"-attribut hvis browserens stylesheet
fortæller hvad den betyder (hvis din kode altså er XML og ikke HTML).

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen skrev:

> Den er ikke standard fordi den er defineret af en
> standard-definerende organisation (de jura) eller er bredt
> udbredt (de fakto). FOr mig betyder det at den slet ikke er en
> standard. Det er dog blot et semantisk problem, fordi vi vist
> ikke er enige om hvad "standard" dækker over.

Det er vel stadig en gyldig DTD? Så vidt jeg husker er det da
beskrevet hvordan man udvider en DTD fra W3's side - det er vel
også fordi man vil give folk muligheden?


> Hvis du tilføjede en ny attribut i DTD'en der hed
> "fnullergøj", så ville du kunne skrive "udvidet HTML" med den
> attribut. Browseren har blot ingen chance for at vide hvad du
> mener, og ignorerer derfor attributten.

Det er klart. Man opnår intet ved at tilføje noget i en DTD hvis
der ikke på forhånd er (en vis) browserunderstøttelse af det.

> Du tilføjer en ny attribut i DTD'en der hedder "border", så du
> kan skrive "udvidet HTML" med den attribut. Du har ikke
> fortalt browseren hvad border betyder,

Nej - men DTD'en er jo skrevet specifikt til visse browserers
forståelse af "border". Hvis alternativet til at vise en given
border er helt at ignorere attributten - så er problemet vel ikke
så stort.


> (den kunne faktisk ignorere alt om dokumentet ud over at det er
> et XML-dokument).

Sådan er der bare ingen browsere der opfører sig. Når man for
eksempel har valgt at et ukendt doctype sætter standardmode er det
i mine øjne tegn på at man de facto accepterer at der kan komme nye
standarder (officielle som uofficielle).

> Derfor er du "heldig" at browserne er så tilgivende over for
> folk der ikke kan finde ud af at skrive en rigtigt
> dokumenttype, og derfor også hjælper dig, der skriver en
> dokumenttype som browseren ikke forstår.

Hvis browserne ikke opførte sig således ville det være problematisk
at indføre nye officielle standarder. Forestil dig hvordan man
skulle få udbredt en ny standard hvis den kun er brugbar i browsere
der specifikt har implementeret standarden.

--
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" <jc@dmf.dk> writes:

> Det er vel stadig en gyldig DTD? Så vidt jeg husker er det da
> beskrevet hvordan man udvider en DTD fra W3's side - det er vel
> også fordi man vil give folk muligheden?

Ja da. Det er en standard-opfyldende SGML-applikation. Det er stadig
ikke (i mine øjne) en standard-definerende HTML-definition.

> Nej - men DTD'en er jo skrevet specifikt til visse browserers
> forståelse af "border". Hvis alternativet til at vise en given
> border er helt at ignorere attributten - så er problemet vel ikke
> så stort.

Det er rigtigt. Det eneste du kan frygte er, at der kommer en ny
browser som siger "den dokumenttype kender jeg ikke, så jeg behandler
den som ren XML". Den vil så ignorere alle HTML-attributter der
ikke er specifikt nævnt i dens CSS-regler. Det sker nok ikke.

Hmm, jeg har glemt: Hvad var formålet med at siden skulle validere?

> Sådan er der bare ingen browsere der opfører sig. Når man for
> eksempel har valgt at et ukendt doctype sætter standardmode er det
> i mine øjne tegn på at man de facto accepterer at der kan komme nye
> standarder (officielle som uofficielle).

Det gør den under antagelsen at nye standarder vil være delvist
kompatible med tidligere. Det er en rimelig antagelse, og det har da
også holdt indtil videre.

> Hvis browserne ikke opførte sig således ville det være problematisk
> at indføre nye officielle standarder. Forestil dig hvordan man
> skulle få udbredt en ny standard hvis den kun er brugbar i browsere
> der specifikt har implementeret standarden.

Hvis den nye standard udvider sproget, så vil den gamle browser stadig
ikke forstå disse udvidelser. Den kan godt læse DTD'en, men det
fortæller ikke hvad udvidelsen betyder. Hvis der sammen med DTD'en
fulgte en CSS-specifikation af hvad syntaksen betyder (i det omfang
det er muligt, ikke alt kan specificeres med CSS), så ville browseren
have en mulighed for også at forstå den nye definition.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:

> Hvis du tilføjede en ny attribut i DTD'en der hed "fnullergøj", så
> ville du kunne skrive "udvidet HTML" med den attribut. Browseren
> har blot ingen chance for at vide hvad du mener, og ignorerer
> derfor attributten.

Netop - men nu ligger landet sådan, at border-attributten er defineret
i de browsere jeg tidligere har nævnt, og derfor godt ved hvad
attributtet skal gøre. Derfor vil den ikke blive ignoreret.

> Du tilføjer en ny attribut i DTD'en der hedder "border", så du kan
> skrive "udvidet HTML" med den attribut. Du har ikke fortalt
> browseren hvad border betyder, og den kunne godt tillade sig, ud
> fra at den ikke kender dokumenttypen, at ignorere attributten (den
> kunne faktisk ignorere alt om dokumentet ud over at det er et
> XML-dokument). Det gør den ikke, den *gætter* på at attributten
> betyder det samme som i en dokumenttype den forstår.

En DTD fortæller jo ikke hvordan et element eller et attribut skal
tolkes af en browser. DTD angiver udelukkende retningslinier for
hvordan syntaxen skal være.

For header-elementerne f.eks., er der jo ikke i DTD'en angivet, hvor
stor margin rundt om teksten skal være. Det er "default-defineret" af
browserene, med mindre man selv definerer det med CSS.

> Derfor er du "heldig" at browserne er så tilgivende over for folk
> der ikke kan finde ud af at skrive en rigtigt dokumenttype, og
> derfor også hjælper dig, der skriver en dokumenttype som browseren
> ikke forstår.

Jeg er ikke helt med her - mener du, at min dokumenttype er forkert?
Det behøver jo ikke, at være forkert, bare fordi det ikke er W3C der
har lavet det.

--
Martin

---

Erik Ginnerskov skrev:

> Hvis vi allesammen går rundt og opfinder vores egne
> standarder, bare for at kunne få vores håbløse sider til at
> validere, i stedet for at overholde den standard, som W3C
> anbefaler, hvad skal de stakkels browserprogrammører så rette
> sig efter.

W3 retter sig nok efter de retningslinjer de nu engang har. Jeg har
svært ved at se at det pludseligt skulle blive "mode" at skrive
sine egne DTD'er i en sådan grad at de officielle DTD'er skulle
blive værdiløse.

> Det ender da med at blive et stort uoverskueligt rod. Så vil
> det da være mere hensigtsmæssigt at læne sig så kraftigt op ad
> de vise herrer i W3c, så at de muliggør fjernelse af synlig
> border i frameset - efter en fælles standard.

Det er også et udmærket forslag - men ikke meget værd hvis man skal
skrive en side her og nu.

> Som Lasse R antydede i en anden tråd om samme emne: Martin, du
> er så langt ude over kanten, at du ikke længere har kontakt
> til skråplanet.
>
> Du direkte modarbejder mange menneskers forsøg på at etablere
> én fælles standard, som alle browsere forstår og som alle
> Web-designere kan (lære at) finde ud af at skrive til.

Det kan jeg simpelthen ikke se. Hvis Martin lavede DTD'er der var
inkompatible med W3's og han samtidig brugte energi på at promovere
disse DTD'er - så kan jeg måske se et problem. Det er der bare ikke
tale om. I det aktuelle tilfælde (med frameborder) er der tre
muligheder som webdesigner:

Man kan...
1) Acceptere at siden kommer til at se anderledes ud end ønsket
2) Lave en side der ikke validerer
3) Lave en side der validerer med en udvidet DTD

Formentlig er det mest almindelige valg (i praksis) 2. Det er i
mine øjne mere skadeligt for tanken om at nå en fælles standard for
HTML end at bruge 3.

Fordelen ved at bruge 3 er at man stadig kan validere sin side mod
fx W3's validator. Man kan ikke hævde at bruge valid XHTML
(medmindre man tydligt angiver at det er en modificeret udgave) -
men det er jo heller ikke tilfældet her.

Uanset valg af DTD er man underlagt de forskellige
browserproducenters implementationer af (X)HTML og CSS. Så vidt jeg
ved bruges doctypen i dag alene til at sætte standard- eller
quirks-mode. En modificeret doctype vil få browsere til at gå i
standardmode så hvis man alligevel gerne vil benytte standardmode
giver det ikke praktiske problemer at vælge sin egen doctype.
--
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

---

Andreas Haugstrup Pedersen skrev:

[hjemmegjort DTD]

> Rent teknisk kan den være fin fin, men i og med den ikke er
> understøttet eller anerkendt er den ubrugelig.

Den er da nydeligt understøttet.

- Browserunderstøttelsen er fin - de 99 % af DTD'en som er
sammenfaldende med den officiellle DTD vises af alle browsere, mens
selve udvidelsen (mindst) vises af de mest udbredte
windowsbrowsere.

- Validatortjenesten på W3C brokker sig heller ikke. Man kan
validere mod den hjemmegjorte DTD og få at vide at dokumentet
overholder de retningslinjer man selv har fastlagt.

Den er på ingen måde ubrugelig.

Hvis man vil bruge en DTD til at implementere en dingenot der ikke
er understøttet i nogle browsere hjælper det selvfølgelig ikke så
meget. Men i tilfældet her kan jeg godt se en fidus i en tilrettet
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

---

Andreas Haugstrup Pedersen skrev:

> Doctype bruges til at angive hvilken version af HTML du bruger
> i det aktuelle dokument.

Ikke af browserne. De bruger doctypen til at afgøre om en side skal
vises i standard- eller quirks-mode (såfremt siden ser ud til at
være en html-side).

> Når du ikke bruger en af de af W3C
> angivne DTD'er kan browseren i bedste fald gætte på.. ukendt.
> Browseren har ikke en chance for at vide hvad det er du
> skriver. Hvis du er heldig hopper browseren i en eller anden
> quirks-mode fordi du ikke har angivet en gyldig HTML DTD.

Nej - som jeg har skrevet før vil en ukendt doctype *ikke* sætte
quirks mode - og det er en ganske fornuftig opførsel. Hvis W3C i
morgen godkender XHTML 1.2 vil ingen af de nuværende browsere kunne
understøtte den hvis man skal følge dit argument. Det ville være
direkte tåbeligt hvis browserne ikke skulle kunne benytte en ny
doctype.

Naturligvis kan (og vil) der være nyskabelser i en ny DTD - disse
vil formentlig ikke være understøttet. Men langt hovedparten af en
ny DTD vil normalt være genbrug af en eksisterende DTD - derfor
giver det god mening at browserne også accepterer en standard de
ikke umiddelbart forstår.

> At dine tre browsere fjerner border er mere held end forstand.
> Du har ingen mulighed for at vide om det ændrer sig med den
> næste browserudgivelse.

Browserproducenterne har det med at være ret glade for
bagudkompatibilitet - det er formentlig derfor at border-tricket
virker i første omgang. Du har da ret i at det ikke er
fremtidssikret at benytte sig af eksisterende browseres unoder -
men det ændrer ikke ved at tricket vil virke her og nu for en meget
stor del af brugerne, samt at siden i de tilfælde hvor det _ikke_
virker stadig vil kunne læses uden problemer.
--
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

---

Lasse Reichstein Nielsen skrev:

> Hmm, jeg har glemt: Hvad var formålet med at siden skulle
> validere?

Nu er det ikke min side - men i mine øjne er der to formål:

a) Valid kode er bedre end ikke-valid kode (uanset om det så er
valid HTML eller valid "høkerHTML")

b) Valid kode kan valideres maskinelt. Det vil sige at man kan få
W3's validator til at tjekke for syntaksfejl. Når 99 % af den
udvidede DTD er magen til en officiel DTD vil en sådan validering
også give en rimelig sikkerhed for at siden kan vises korrekt.

[om browsere]
> ... de facto accepterer at der kan komme nye standarder
> (officielle som uofficielle).
>
> Det gør den under antagelsen at nye standarder vil være
> delvist kompatible med tidligere. Det er en rimelig antagelse,
> og det har da også holdt indtil videre.

Bestemt. Det samme kan siges om Martins udvidede DTD. Hvis den
udvidede DTD ikke lignede en officiel DTD ville den være ubrugelig.
--
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> writes:

> Lasse Reichstein Nielsen skrev:
>
> > Hmm, jeg har glemt: Hvad var formålet med at siden skulle
> > validere?
>
> Nu er det ikke min side - men i mine øjne er der to formål:
>
> a) Valid kode er bedre end ikke-valid kode (uanset om det så er
> valid HTML eller valid "høkerHTML")

Hvorfor?
Der må være en grund, og jeg har en fornemmelse af at den grund går
i fløjten hvis man bruger sin egen definition at validere efter ...
så kan alt jo validere, bare taggene er matchede.

> b) Valid kode kan valideres maskinelt. Det vil sige at man kan få
> W3's validator til at tjekke for syntaksfejl. Når 99 % af den
> udvidede DTD er magen til en officiel DTD vil en sådan validering
> også give en rimelig sikkerhed for at siden kan vises korrekt.

Det samme kan man sige om en side med hundrede linjer kode der kun har
en fejl i valideringen. Hvorfor er fejlfri validering med en
næsten-standard DTD bedre end næsten-validering med en standard DTD?

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:

> Det samme kan man sige om en side med hundrede linjer kode der kun
> har en fejl i valideringen. Hvorfor er fejlfri validering med en
> næsten-standard DTD bedre end næsten-validering med en standard
> DTD?

For mig at se kan det næsten kun være et personligt anliggende. Jeg
synes det er spild af tid, at definere en DTD hvis man alligevel ikke
gider leve op til den.

--
Martin

---

Lasse Reichstein Nielsen skrev:

>> a) Valid kode er bedre end ikke-valid kode

> Hvorfor?
> Der må være en grund, og jeg har en fornemmelse af at den
> grund går i fløjten hvis man bruger sin egen definition at
> validere efter ... så kan alt jo validere, bare taggene er
> matchede.

Fordi man skal holde hvad man lover. I doctypen angiver man hvilke
regler der skal gælde for det aktuelle dokument. Hvis man ikke
overholder retningslinjerne i den DTD man har angivet (og dermed
bruger ikke-valid kode) så bruger man en DTD forkert.


> Hvorfor er fejlfri validering med en næsten-standard DTD bedre
> end næsten-validering med en standard DTD?

Fordi det er mange gange lettere at skelne mellem valid kontra
ikke-valid kode end det er at skelne mellem næsten-men-o.k.-valid
og næsten-men-ikke-o.k.-kode.

Hvis man validerer en side baseret på en udvidet DTD, og man fx har
glemt at slette en </p> så vil det fremgå lynhurtigt ved en
validering - fordi siden normalt vil validere. Omvendt er det hvis
man bruger en DTD der altid giver 1 eller 2 fejl. Her skal man ind
og fortolke de fejlmeddelelser en validering giver: "er det en fejl
vi har valgt at acceptere eller ej?"

(NB: Jeg har ikke testet hvor godt W3's validator fungerer i
forhold til Martin Poulsens DTD. Siden kan valideres med
validatoren, men spørgsmålet er om den undersøger hele HTML'en lige
så grundigt som ved en normal DTD. Det er hurtigt at afprøve med en
test - forslaget er hermed stillet)
--
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 wrote:

> (NB: Jeg har ikke testet hvor godt W3's validator fungerer i
> forhold til Martin Poulsens DTD. Siden kan valideres med
> validatoren, men spørgsmålet er om den undersøger hele HTML'en lige
> så grundigt som ved en normal DTD. Det er hurtigt at afprøve med en
> test - forslaget er hermed stillet)

Jeg har i min DTD defineret frameset-elementet som følgende:

<!ELEMENT frameset (frameset|frame|noframes)*>
<!ATTLIST frameset
%coreattrs;
rows %MultiLengths; #IMPLIED
cols %MultiLengths; #IMPLIED
border (1|0) "1"
onload %Script; #IMPLIED
onunload %Script; #IMPLIED
>

border-attributtet kan altså kun antage to gyldige værdier (1 og 0).
For at teste hvor godt W3C Validatoren kontrollerede dokumentet,
satte jeg værdien for border-attributtet til 2, og fik derefter
følgende tilbagemelding:

Below are the results of attempting to parse this document with an
SGML parser.

1. Line 9, column 19: value of attribute "border" cannot be "2";
must be one of "1", "0" (explain...).

<frameset border="2" cols="50, 50">
^

Jeg antager derfor, at den tester mindst ligeså godt, som ved en
"normal" DTD. Jeg går ud fra, at det var sådan en test, du
efterlyste?

--
Martin

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> writes:

> Fordi man skal holde hvad man lover. I doctypen angiver man hvilke
> regler der skal gælde for det aktuelle dokument. Hvis man ikke
> overholder retningslinjerne i den DTD man har angivet (og dermed
> bruger ikke-valid kode) så bruger man en DTD forkert.

Hvis man kan tilpasse DTD'en til dokumentet, så lover man jo ikke
alverden. Man ville være lige så godt stillet ved ikke at love noget
(altså ingen dokumenttype angivet i dokumentet).

Det vil sætte browseren i quirks-mode, men er det den eneste grund til
at have en dokumenttype?

> Fordi det er mange gange lettere at skelne mellem valid kontra
> ikke-valid kode end det er at skelne mellem næsten-men-o.k.-valid
> og næsten-men-ikke-o.k.-kode.

Det er en pointe!

men, hvis man validere sin side af hensyn til sig selv (for at finde
fejl), så kan man gøre ud fra sin egen DTD uden at skrive noget i
HTML-siden om det.

Hvorfor skal man have en dokumenttype i HTML-siden (ud over for at
tvinge dumme browsere til at følge standarder)?

/L 'Advocatus Diabloi'
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

---

Martin Poulsen skrev:

> Jeg antager derfor, at den tester mindst ligeså godt, som ved
> en "normal" DTD. Jeg går ud fra, at det var sådan en test, du
> efterlyste?

Ja. Jeg ville have testet om den fandt fejl i den del af DTD'en der
svarer til den oprindelige (W3-autoriserede) DTD - men ud fra den
fejlmeddelelse du fik i din test vil jeg stærkt gå ud fra at fejl i
den "normale" del af DTD'en også fanges.
--
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

---

Lasse Reichstein Nielsen skrev:

> Hvis man kan tilpasse DTD'en til dokumentet, så lover man jo
> ikke alverden.

Jo - man lover at følge det som DTD'en beskriver. Hvis DTD'en
ligger langt fra en officiel standard er løftet måske ikke så meget
værd i praksis, men når det som her er en DTD der er næsten
identisk med en officiel godkendt DTD betyder løftet ikke så lidt.

> Man ville være lige så godt stillet ved ikke at
> love noget (altså ingen dokumenttype angivet i dokumentet).

Hvis man gerne vil underlægge sig en given dokumenttype - og dermed
sikre at man skriver dokumenter der er gyldige i den givne type -
så er det en god ide at sætte en DTD.
Under alle omstændigheder er DTD'en det der muliggør en automatisk
validering.


> Det vil sætte browseren i quirks-mode, men er det den eneste
> grund til at have en dokumenttype?

I browserøjemed, ja. Men som udvikler er det (i mine øjne) vigtigt
at kunne kontrollere den kode man skriver. I egentlig programkode
har man en parser der kan finde syntaksfejl med mere. HTML har ikke
en sådan parser, men man har muligheden for at validere koden
maskinelt. Det er et vigtigt arbejdsredskab til at sikre korrekt
opbygget kode. Uden en DTD kan dette redskab ikke benyttes.


> men, hvis man validere sin side af hensyn til sig selv (for at
> finde fejl), så kan man gøre ud fra sin egen DTD uden at
> skrive noget i HTML-siden om det.

Hvis man skriver sin egen validator kan man sikkert godt - men
hvorfor er det så galt at benytte en officiel validator. W3's
validator kan uden problemer validere i forhold til en
specialiseret DTD.


> Hvorfor skal man have en dokumenttype i HTML-siden (ud over
> for at tvinge dumme browsere til at følge standarder)?

Nu har alle de store browsere vist efterhånden implementeret quirks
mode til dokumenter uden en DTD - så browserspørgsmålet er ret
essentielt. Men derudover er der stadig spørgsmålet om validering
af koden. Jeg validerer normalt alle sider med mozilla-dingenoten
"checky" som er sat op til at validere mod W3's HTML- og css-
validatorer. Når muligheden for at validere et dokument
baseret på en specialiseret DTD findes ser jeg ingen grunde til at
finde på alternative måder at validere på.

> /L 'Advocatus Diabloi'

Hov - jeg troede at det var undertegnede og Martin Poulsen der var
på den "forkerte" side
--
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
> Lasse Reichstein Nielsen skrev:
>
> > men, hvis man validere sin side af hensyn til sig selv (for at
> > finde fejl), så kan man gøre ud fra sin egen DTD uden at
> > skrive noget i HTML-siden om det.
>
> Hvis man skriver sin egen validator kan man sikkert godt - men
> hvorfor er det så galt at benytte en officiel validator. W3's
> validator kan uden problemer validere i forhold til en
> specialiseret DTD.

Når det nu bare drejer sig om at få browserne til at fjerne den grimme hvide
streg mellem de enkelte frames, kan man da præcis lige så vel nøjes med at
validere efter standard-dtd'er, indtil der kun kommer fejlmelding vedrørende
frameset=0. Så har man opnået nøjagtig det samme, uden at bruge timer på at
definere en speciel dtd, der kan få en validator til at godkende
attributten.

--
Med venlig hilsen
Erik Ginnerskov - erik snabela ginnerskov dot dk
http://www.hjemmesideskolen.dk - http://www.html-faq.dk
http://hjem.get2net.dk/sorgin

---

Erik Ginnerskov skrev:

> Du har for så vidt forklaret dine hensigter godt nok, men når
> så i din dtd kalder det, du har lavet for xhtml 1.0 extended

Det er xhtml 1.0 + en ekstra definition - det virker ganske logisk
at kalde det xhtml extended.

> og kalder din side for valid xhtml 1.0.,

Hvor har Martin gjort det? Det står ikke på siden og så vidt jeg
husker har han heller ikke skrevet noget om at siden skulle kaldes
"valid XHTML" her i tråden.

> Xhtml 1.0 er en standard lavet af W3C. Den udvidelse du laver
> fratager dig retten til at kalde din dtd for xhtml 1.0 med
> eller uden tilføjelsen extended.

Kan du dokumentere det?

Se evt. følgende citat fra <http://www.w3.org/TR/xhtml1/#defs>

,---- [ 4 ]
| There must be a DOCTYPE declaration in the document prior to the
| root element. The public identifier included in the DOCTYPE
| declaration must reference one of the three DTDs found in DTDs
| using the respective Formal Public Identifier. The system
| identifier may be changed to reflect local system conventions.
`----

Og herefter:

,---- [ 5 ]
| The DTD subset must not be used to override any parameter entities
| in the DTD.
`----

Så vidt jeg kan læse de to punkter er det altså tilladt at lave en
lokalt tilpasset system identifier, sålænge man ikke redefinerer
eksisterende attributter.


> Og din side består af tohundrede linjer doctypedefinitioner,
> men jeg kunne overhovedet ikke få øje på noget som helst, der
> berettiger, at du kalder siden noget med html.

Hvad? Taler vi om html-siden <http://users.cybercity.dk/~dsl85798/>
eller om DTD-definitionen
<http://users.cybercity.dk/~dsl85798/doctype/xhtml1-extended-
frameset.dtd> ?

DTD-definitionen ligner ikke HTML - men det _er_ heller ikke HTML.
Prøv at sammenligne med den originale frameset-DTD:
<http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.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

---

Erik Ginnerskov skrev:

> Når det nu bare drejer sig om at få browserne til at fjerne
> den grimme hvide streg mellem de enkelte frames, kan man da
> præcis lige så vel nøjes med at validere efter
> standard-dtd'er, indtil der kun kommer fejlmelding vedrørende
> frameset=0.

Som jeg har skrevet før så er det væsentlig lettere at skelne
mellem "fejl" og "ingen fejl" end det er at skelne mellem "fejl-
der-accepteres" og "fejl-der-accepteres-samt-fejl-der-ikke-
accepteres".

> Så har man opnået nøjagtig det samme, uden at
> bruge timer på at definere en speciel dtd, der kan få en
> validator til at godkende attributten.

Nu er vi ovre i en cost-benefit-analyse. Hvis det tager flere timer
at udvide en eksisterende DTD kan det måske ikke betale sig - men
hvad nu hvis det kan klares på fem minutter? Syntaksen er klar i
forvejen, og hvis man ved hvad attributten skal indeholde behøver
det ikke tage lang tid.
--
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
> Erik Ginnerskov skrev:
>
> > Når det nu bare drejer sig om at få browserne til at fjerne
> > den grimme hvide streg mellem de enkelte frames, kan man da
> > præcis lige så vel nøjes med at validere efter
> > standard-dtd'er, indtil der kun kommer fejlmelding vedrørende
> > frameset=0.
>
> Som jeg har skrevet før så er det væsentlig lettere at skelne
> mellem "fejl" og "ingen fejl" end det er at skelne mellem "fejl-
> der-accepteres" og "fejl-der-accepteres-samt-fejl-der-ikke-
> accepteres".

En helt syvende mulighed ville så være at validere framesettet som html 3.2.

--
Med venlig hilsen
Erik Ginnerskov - erik snabela ginnerskov dot dk
http://www.hjemmesideskolen.dk - http://www.html-faq.dk
http://hjem.get2net.dk/sorgin

---

Erik Ginnerskov wrote:

> En helt syvende mulighed ville så være at validere framesettet som
> html 3.2.

Det bliver nok svært, eftersom frames først kom til verden med HTML 4.

--
Martin

---

Erik Ginnerskov skrev:

> En helt syvende mulighed ville så være at validere framesettet
> som html 3.2.

Så er man tilbage ved problemet med browsermode (jeg går ud fra at
HTML 3.2 vil sætte quirks mode). Desuden kan jeg forestille mig at
man vil savne en del HTML 4-elementer. Men det er da en mulighed.
--
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