---

Hejsa.

Siden fyn.netvaerk.org vil ikke validere. Jeg har rettet de fejl, jeg
forstår. Men en makker har hjulpet mig på nogle områder, og disse fejl
tør jeg ikke pille ved uden jeres accept :)

De fleste fejl er i denne stil:

Line 21, Column 23: general entity "subpage" not defined and no
default entity .
<a href="?page=forside&subpage=kommentar">Feedback<span>

validatoren ser gerne, at jeg brugere flere ";" ... men hvor og
hvordan skal de placeres?

Desuden er et tilbagevendende problem, at jeg har flere id="menu". Det
skyldes, at jeg også har styles på li og ul i menu. Jeg har prøvet at
lave den til class i stedet for id, men så virker designet ikke mere.
Nogle forslag?

Senga

---

"Senga" <dea_dh@yahoo.com> skrev i en meddelelse
news:1194513012.926009.317470@o80g2000hse.googlegroups.com...
Hejsa.

Siden fyn.netvaerk.org vil ikke validere. Jeg har rettet de fejl, jeg
forstår. Men en makker har hjulpet mig på nogle områder, og disse fejl
tør jeg ikke pille ved uden jeres accept :)

De fleste fejl er i denne stil:

Line 21, Column 23: general entity "subpage" not defined and no
default entity .
<a href="?page=forside&subpage=kommentar">Feedback<span>

validatoren ser gerne, at jeg brugere flere ";" ... men hvor og
hvordan skal de placeres?

Desuden er et tilbagevendende problem, at jeg har flere id="menu". Det
skyldes, at jeg også har styles på li og ul i menu. Jeg har prøvet at
lave den til class i stedet for id, men så virker designet ikke mere.
Nogle forslag?

Senga



Din side er XHTML - som er en hybrid mellem HTML og XML, og fortolkes
strengere end HTML.

Karakteren & betyder at der følger en entitet efter - en måde at angive
specielle karakterer, som f.eks.&copy; (copyright), eller de danske
karakterer æ=&aelig; etc.

& (ampersand) starter entiteten og ; (semikolon) afslutter den - det der
står imellem, er det tegn man ønsker.
I HTML kan man skrive & - når der ikke følger en defineret entitet efter,
bruges så karakteren &.
Det kan man ikke i XHTML.
Her SKAL & skrives som &amp;

Et id skal være unikt.
Igen - i HTML tages ikke så tungt på den slags, og tingene kan fungere, selv
om man ikke overholder reglerne. (I hvert fald så længe man ikke referer til
id'erne i f.eks. script).
Men XHTML er ikke så tilgivende.
Problemet med flere ens id, kan ikke lige løses.

Uden at have set din css igennem :
Du kan prøve, at bruge din menu som klasse i stedet.
I css, skal den så defineres med et punktum foran - også hvor du styler på
ul og li under den.
I HTML skal du have <div class="menu"..> i stedet for <div id="menu"...>

Birger

---

On Thu, 8 Nov 2007 11:06:00 +0100, "Birger" <sdc@bbsorensen.com> wrote:

>Din side er XHTML - som er en hybrid mellem HTML og XML, og fortolkes
>strengere end HTML.

Ikke i f.t. de fejl, der er nævnt her.

<snip>
>Det kan man ikke i XHTML.
>Her SKAL & skrives som &amp;

Skal det også i HTML.

>Et id skal være unikt.
>Igen - i HTML tages ikke så tungt på den slags, og tingene kan fungere, selv
>om man ikke overholder reglerne. (I hvert fald så længe man ikke referer til
>id'erne i f.eks. script).
>Men XHTML er ikke så tilgivende.

Det er HTML heller ikke.

Dine løsninger er rigtige nok, men det er forklaringerne ikke.


Mvh. Jørn

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

---

"Jørn Andersen" <jorn@jorna.dk> skrev i en meddelelse
news:oao5j31lrihlo7g95ru4kq5okfm683k67s@4ax.com...
> On Thu, 8 Nov 2007 11:06:00 +0100, "Birger" <sdc@bbsorensen.com> wrote:
>
>>Din side er XHTML - som er en hybrid mellem HTML og XML, og fortolkes
>>strengere end HTML.
>
> Ikke i f.t. de fejl, der er nævnt her.
>
> <snip>
>>Det kan man ikke i XHTML.
>>Her SKAL & skrives som &amp;
>
> Skal det også i HTML.
>
>>Et id skal være unikt.
>>Igen - i HTML tages ikke så tungt på den slags, og tingene kan fungere,
>>selv
>>om man ikke overholder reglerne. (I hvert fald så længe man ikke referer
>>til
>>id'erne i f.eks. script).
>>Men XHTML er ikke så tilgivende.
>
> Det er HTML heller ikke.
>
> Dine løsninger er rigtige nok, men det er forklaringerne ikke.
>

Mener nu forklaringerne er gode nok. ;>)

De holder så åbenbart bare også når det er HTML.

Har ikke beskæftiget mig med HTML, siden hvadsomhelst blev godtaget - da jeg
startede igen for nylig, blev det i XHTML.

Birger

---

"Birger" skrev...

> De fleste fejl er i denne stil:
>
> Line 21, Column 23: general entity "subpage" not defined and no
> default entity .
> <a href="?page=forside&subpage=kommentar">Feedback<span>
>
> validatoren ser gerne, at jeg brugere flere ";" ... men hvor og
> hvordan skal de placeres?

Ret & til &amp;

Du kan godt regne med, at langt de fleste af de fejl, hvor der står noget
med entity, skal rettes i denne dur. Der findes vidst et par andre tegn, som
også ind i mellem skal rettes, og der findes en liste over tegnene et eller
andet sted, så man har hele striben at konvertere efter, men kan ikke huske
hvor.

Og grunden til, den staller over & det er at dette tegn kan bruges i flere
betydninger - jeg vil tro, at den tror, at & er indledningen til noget mere
(som &amp;), men hvor der jo så mangler resten, og den derfor gir fejl.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Og grunden til, den staller over & det er at dette tegn kan bruges i flere
> betydninger

Nej, egentlig ikke. Hvis man i sin kode skriver "&beholder",
prøver HTML at oversætte det til en entitet (a la "&amp;"), men
da der ikke findes en sådan, meldes der fejl.

Tegnet kan kun bruges i én betydning, og det er "Nu følger der en
legal entitetskode".

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

---

"Bertel Lund Hansen" skrev...
> Rune Jensen skrev:
>
>> Og grunden til, den staller over & det er at dette tegn kan bruges i
>> flere
>> betydninger
>
> Nej, egentlig ikke. Hvis man i sin kode skriver "&beholder",
> prøver HTML at oversætte det til en entitet (a la "&amp;"), men
> da der ikke findes en sådan, meldes der fejl.
>
> Tegnet kan kun bruges i én betydning, og det er "Nu følger der en
> legal entitetskode".

Hmmm... to betydninger for os, én for maskinen
Men ja, du har da ret. Så blev også jeg klogere.


MVH
Rune Jensen

---

Den 08-11-07 10.10 skrev Senga følgende:

> Siden fyn.netvaerk.org vil ikke validere.
>
> Line 21, Column 23: general entity "subpage" not defined and no
> default entity .
> <a href="?page=forside&subpage=kommentar">Feedback<span>

&-tegnet skal kodes specielt, når det står i en url (adresse). Du skal
udskifte "&" med "&amp;".

> Desuden er et tilbagevendende problem, at jeg har flere id="menu". Det
> skyldes, at jeg også har styles på li og ul i menu. Jeg har prøvet at
> lave den til class i stedet for id, men så virker designet ikke mere.
> Nogle forslag?

Du kan evt. lave det om til en klasse i stedet, dem må der gerne være
flere af på en side. Altså: "ul class=menu" og "div class=menu". Du skal
så også rette i stilarket: "#menu" skal ændres til ".menu".

--
Mvh. Kim Ludvigsen
Polimiken - en levende netavis, der tør, hvor selv Ekstra Bladet tier.
http://polimiken.dk

---

"Kim Ludvigsen" skrev...

> &-tegnet skal kodes specielt, når det står i en url (adresse). Du skal
> udskifte "&" med "&amp;".

Jeg mener nu at kunne huske, at & altid vil skabe problemer. Dvs. også hvis
du lægger det i en <p>?


MVH
Rune Jensen

---

Den 08-11-07 11.47 skrev Rune Jensen følgende:
> "Kim Ludvigsen" skrev...
>
>> &-tegnet skal kodes specielt, når det står i en url (adresse). Du skal
>> udskifte "&" med "&amp;".
>
> Jeg mener nu at kunne huske, at & altid vil skabe problemer. Dvs. også hvis
> du lægger det i en <p>?

Prøv at tjekke denne side:
http://80.62.45.5/projekter/og.html

Læg mærke til, at der er & i såvel title som i <h1> og <p>.

--
Mvh. Kim Ludvigsen
Polimiken - en levende netavis, der tør, hvor selv Ekstra Bladet tier.
http://polimiken.dk

---

Kim Ludvigsen wrote:

> Prøv at tjekke denne side:
> http://80.62.45.5/projekter/og.html
>
> Læg mærke til, at der er & i såvel title som i <h1> og <p>.

Men hvis der uden mellemrum følger noget efter &, vil du også i html få
valideringsfejl, da validatoren - som nævnt tidligere i tråden - forsøger at
oversætte det til en for validatoren ukendt entitet.

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

---

"Erik Ginnerskov" skrev...
> Kim Ludvigsen wrote:
>
>> Prøv at tjekke denne side:
>> http://80.62.45.5/projekter/og.html
>>
>> Læg mærke til, at der er & i såvel title som i <h1> og <p>.
>
> Men hvis der uden mellemrum følger noget efter &, vil du også i html få
> valideringsfejl, da validatoren - som nævnt tidligere i tråden - forsøger
> at oversætte det til en for validatoren ukendt entitet.

....og her er en liste over entities:
http://www.w3schools.com/tags/ref_entities.asp

Generelt råd: Bookmark w3schools.com, for den er brugbar rigtig mange
tilfælde, eller brug navnet i søgestrengen på f.eks. Google sammen med dine
andre søgeord (min søgestreng: html entities w3schools).


MVH
Rune Jensen

---

Rune Jensen skrev:

> ...og her er en liste over entities:

Jo, men sådan en skulle helst ikke få nybegyndere til at kode en
masse tegn. Det er kun &, < og > der behøver kodes på en normal
dansk hjemmeside.

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

---

> Jo, men sådan en skulle helst ikke få nybegyndere til at kode en
> masse tegn. Det er kun &, < og > der behøver kodes på en normal
> dansk hjemmeside.

Vil det sige, at det i princippet er i orden (valid html) at skrive æ, ø og
å i stedet for &aelig;, &oslash; og &aring;?
Jeg ved godt, at I ikke vil anbefale det, men jeg har godt nok studset over,
at jeg ikke har fået fejlmeldinger på dén konto.

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i en meddelelse
news:47357107$0$15878$edfadb0f@dtext01.news.tele.dk...
>> Jo, men sådan en skulle helst ikke få nybegyndere til at kode en
>> masse tegn. Det er kun &, < og > der behøver kodes på en normal
>> dansk hjemmeside.
>
> Vil det sige, at det i princippet er i orden (valid html) at skrive æ, ø
> og å i stedet for &aelig;, &oslash; og &aring;?
> Jeg ved godt, at I ikke vil anbefale det, men jeg har godt nok studset
> over, at jeg ikke har fået fejlmeldinger på dén konto.


http://msdn2.microsoft.com/en-us/library/ms537497.aspx
http://msdn2.microsoft.com/en-us/library/ms537499.aspx

Bertel : hvad er "en normal dansk hjemmeside"?

Philip : Det kommer an på charset. ISO-8859-1 forstår de danske karakterer -
tror ikke der er så amnge andre der gør det.

Birger

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev :

>Vil det sige, at det i princippet er i orden (valid html) at skrive æ, ø og
>å i stedet for &aelig;, &oslash; og &aring;?

Ja da.

>Jeg ved godt, at I ikke vil anbefale det, men jeg har godt nok studset over,
>at jeg ikke har fået fejlmeldinger på dén konto.

Vi anbefaler da absolut at bruge de danske bogstaver.
Blot skal man huske at definere tegnsætning i <head>,
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-1">.

Selv uden vil som regel også gå godt, men dels er ovennævnte et
krav for validering og dels af hensyn til udenlandske besøgende,
som kommer fra et område med anden tegnsætning end vesteuropæisk.

--
Kerim
»Søger nogen en anden religion end Islam, skal den ikke modtages
af Ham, og han skal i det kommende liv være blandt taberne.«
(Sura 3, vers 87)

---

> Vi anbefaler da absolut at bruge de danske bogstaver.

Det var dagens gode nyhed.

> Blot skal man huske at definere tegnsætning i <head>,
> <meta http-equiv="content-type" content="text/html;
> charset=iso-8859-1">.

Det har jeg heldigvis gjort som standard.

> Selv uden vil som regel også gå godt, men dels er ovennævnte et
> krav for validering og dels af hensyn til udenlandske besøgende,
> som kommer fra et område med anden tegnsætning end vesteuropæisk.

Jeg forstår det sådan, at med det rigtige charset vil man også se det
rigtige tegn, selv om man sidder computer udenfor Europa.

---

Philip Nunnegaard skrev:

> Jeg forstår det sådan, at med det rigtige charset vil man også se det
> rigtige tegn, selv om man sidder computer udenfor Europa.

Nemlig, og det validerer. Jeg havde for mange år siden undladt at
erklære tegnsæt. Der var en fyr fra Hongkong der skrev og bad mig
om at gøre det, for ellers kunne han ikke læse Fidusos sider. Med
korrekt erklæret tegnsæt i koden kunne hans asiatiske system vise
siderne rigtigt.

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

---

Den 10-11-07 09.51 skrev Philip Nunnegaard følgende:
>> Jo, men sådan en skulle helst ikke få nybegyndere til at kode en
>> masse tegn. Det er kun &, < og > der behøver kodes på en normal
>> dansk hjemmeside.
>
> Vil det sige, at det i princippet er i orden (valid html) at skrive æ, ø og
> å i stedet for &aelig;, &oslash; og &aring;?

Der er absolut ingen grund til at bruge &aelig; osv. Det kunne være en
nødvendighed i midten af 90'erne, men i dag kan du blot angive
tegnsættet som iso-8859-1 eller utf-8 og så skrive æ, ø og å.

Der kan dog være undtagelser, hvis du bruger et eksotisk styresystem som
fx OS/2 og vist også Mac OS. Men i så fald er løsningen ikke at skrive
&aelig; osv, men i stedet at gemme teksten med det rette tegnsæt i
stedet for styresystemets standardtegnsæt.

> Jeg ved godt, at I ikke vil anbefale det

Jeg tror ikke, der er nogle herinde, der vil anbefale brugen af &aelig; osv.

--
Mvh. Kim Ludvigsen
Polimiken - en levende netavis, der tør, hvor selv Ekstra Bladet tier.
http://polimiken.dk

---

On Sat, 10 Nov 2007 10:45:11 +0100, Kim Ludvigsen
<usenet@kimludvigsen.dk> wrote:

>Der er absolut ingen grund til at bruge &aelig; osv. Det kunne være en
>nødvendighed i midten af 90'erne, men i dag kan du blot angive
>tegnsættet som iso-8859-1 eller utf-8 og så skrive æ, ø og å.

En - lidt speciel - grund kan være, hvis man sidder med fx et
US-tastatur og gider huske tastatur-koderne ...


Mvh. Jørn

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

---

On Sun, 11 Nov 2007 02:22:52 +0100, Jørn Andersen <jorn@jorna.dk> wrote:

>En - lidt speciel - grund kan være, hvis man sidder med fx et
>US-tastatur og gider huske tastatur-koderne ...

Der skulle selvfølgelig stå *ikke* gider ...


Mvh. Jørn

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

---

"Jørn Andersen" skrev...

> On Sat, 10 Nov 2007 10:45:11 +0100, Kim Ludvigsen wrote:
>
>>Der er absolut ingen grund til at bruge &aelig; osv. Det kunne være en
>>nødvendighed i midten af 90'erne, men i dag kan du blot angive
>>tegnsættet som iso-8859-1 eller utf-8 og så skrive æ, ø og å.
>
> En - lidt speciel - grund kan være, hvis man sidder med fx et
> US-tastatur og gider huske tastatur-koderne ...

Ja - men en helt legitim grund er referering af kode. Her kan det ikke
undgås. F.eks. skal jeg have listet et længere kodestykke på min side - dvs
den skal vises, ikke udføres. Her er lille uddrag:

&lt;label for=&quot;homepage&quot;&gt;Hjemmeside:&lt;/label&gt;

Hvilket gerne skulle vises på siden i browseren som:

<label for="homepage">Hjemmeside:</label>

....men nej, det koder man selvfølgelig ikke selv, men lader gøre serverside.
Ellers er det ALT for besværligt. I ASP findes funktionen HTMLencode til
nøjagtigt dét.


MVH
Rune Jensen

--
http://runejensen.dk

---

Rune Jensen wrote:
> "Jørn Andersen" skrev...
>
>> On Sat, 10 Nov 2007 10:45:11 +0100, Kim Ludvigsen wrote:
>>
>>> Der er absolut ingen grund til at bruge &aelig; osv. Det kunne være en
>>> nødvendighed i midten af 90'erne, men i dag kan du blot angive
>>> tegnsættet som iso-8859-1 eller utf-8 og så skrive æ, ø og å.
>> En - lidt speciel - grund kan være, hvis man sidder med fx et
>> US-tastatur og gider huske tastatur-koderne ...
>
> Ja - men en helt legitim grund er referering af kode. Her kan det ikke
> undgås.

Sludder og vrøvl. Det kan sagtens undgås; se nederst i dette indlæg.

> F.eks. skal jeg have listet et længere kodestykke på min side - dvs
> den skal vises, ikke udføres. Her er lille uddrag:
>
> &lt;label for=&quot;homepage&quot;&gt;Hjemmeside:&lt;/label&gt;

Som tidligere nævnt her i tråden, er der ingen grund til at bruge
character entity references for " og >. Følgende virker fint:

<pre>
&lt;label for="homepage">Hjemmeside:&lt;/label>
</pre>

> Hvilket gerne skulle vises på siden i browseren som:
>
> <label for="homepage">Hjemmeside:</label>
>
> ...men nej, det koder man selvfølgelig ikke selv, men lader gøre serverside.

Det kan du gøre. Så kan vi andre bruge xmp-elementet:

<xmp>
<label for="homepage">Hjemmeside:</label>
</xmp>

---

"John S. Thomsen" <john.s.thomsen@gmail.com> skrev i en meddelelse
news:473f9739$0$2102$edfadb0f@dtext02.news.tele.dk...

8X

> <pre>
> &lt;label for="homepage">Hjemmeside:&lt;/label>
> </pre>
>
>> Hvilket gerne skulle vises på siden i browseren som:
>>
>> <label for="homepage">Hjemmeside:</label>
>>
>> ...men nej, det koder man selvfølgelig ikke selv, men lader gøre
>> serverside.
>
> Det kan du gøre. Så kan vi andre bruge xmp-elementet:
>
> <xmp>
> <label for="homepage">Hjemmeside:</label>
> </xmp>


http://msdn2.microsoft.com/en-us/library/ms535919.aspx

<xmp> virker så - formentlig - kun i IE.

Fra HTML 3.2 hedder det <pre> eller <samp>

Og fra HTML 4 fremad, eksisterer disse tags vist ikke længere.


Birger

---

"Birger" skrev...

> Fra HTML 3.2 hedder det <pre> eller <samp>

Der skal vidst stadig encodes i <pre>, den sørger bare for at vise
formatteringen nøjagtigt som i HTML-koden.

Anyway, hvis man kigger på, hvordan alle andre gør, så kan man se, de fleste
også encoder HTML, når der skal vises meget kode. Specielt, hvis det er CMS
kan jeg ikke se, det kan betale sig andet, når HTMLencode funktionen er
gratis, og man kan se, den virker.

Dog kan jeg godt se, det ikke er nødvendigt at encode " , det ved jeg ikke
hvorfor man gør, hvis det sættes i <pre> og <code>


MVH
Rune Jensen

---

Rune Jensen wrote:
> "Birger" skrev...
>
>> Fra HTML 3.2 hedder det <pre> eller <samp>
>
> Der skal vidst stadig encodes i <pre>, den sørger bare for at vise
> formatteringen nøjagtigt som i HTML-koden.

Ja, der skal stadig kodes, når man bruger <pre>.

> Anyway, hvis man kigger på, hvordan alle andre gør, så kan man se, de fleste
> også encoder HTML, når der skal vises meget kode. Specielt, hvis det er CMS
> kan jeg ikke se, det kan betale sig andet [...]

Fuldstændig enig, men CM-systemer laver heller ikke håndværk på
klientsiden. De gør det serverside. En meget stor forskel.

---

"John S. Thomsen" skrev...

> Rune Jensen wrote:

>> Anyway, hvis man kigger på, hvordan alle andre gør, så kan man se, de
>> fleste også encoder HTML, når der skal vises meget kode. Specielt, hvis
>> det er CMS kan jeg ikke se, det kan betale sig andet [...]
>
> Fuldstændig enig, men CM-systemer laver heller ikke håndværk på
> klientsiden. De gør det serverside. En meget stor forskel.

Jeg har nu prøvet engang for lang tid siden at sidde og decode en kodeblok i
hånden. Det er rent tidsspild, og også derfor jeg gik over til at lave det
serverside, såsnart det er mere end én linje. Kendte så heller ikke <xmp>
dengang, måske fordi den er deprecated, så står der ikke meget om den de
steder jeg normalt kigger. Men den er smart, hvis den virker. Der må så bare
være en grund til, den er forældet.

MVH
Rune Jensen

---

"Rune Jensen" <runeofdenmark@hotmail.com> skrev i en meddelelse
news:474067f3$0$15015$456a7185@news.cirque.dk...
> "John S. Thomsen" skrev...
>
>> Rune Jensen wrote:
>
>>> Anyway, hvis man kigger på, hvordan alle andre gør, så kan man se, de
>>> fleste også encoder HTML, når der skal vises meget kode. Specielt, hvis
>>> det er CMS kan jeg ikke se, det kan betale sig andet [...]
>>
>> Fuldstændig enig, men CM-systemer laver heller ikke håndværk på
>> klientsiden. De gør det serverside. En meget stor forskel.
>
> Jeg har nu prøvet engang for lang tid siden at sidde og decode en kodeblok
> i hånden. Det er rent tidsspild, og også derfor jeg gik over til at lave
> det serverside, såsnart det er mere end én linje. Kendte så heller ikke
> <xmp> dengang, måske fordi den er deprecated, så står der ikke meget om
> den de steder jeg normalt kigger. Men den er smart, hvis den virker. Der
> må så bare være en grund til, den er forældet.
>
> MVH
> Rune Jensen
>

Skal man skrive HTML så koden ses på siden, er en anden mulighed at sætte
den i et textarea - der bliver det ikke fortolket.

Birger

---

"Birger" ...

> Skal man skrive HTML så koden ses på siden, er en anden mulighed at sætte
> den i et textarea - der bliver det ikke fortolket.

Det vidste jeg så ikke. Eller har måske ikke tænkt over. Så er det
selvfølgelig i nogle tilfælde lidt overkill at bruge serverside, som jeg
selv gør. Man skal vel bare huske, at hvis koden, man skal have i text-area
selv indeholder text.-area, så skal denne encodes. Men jo, nemmere er det.


MVH
Rune Jensen

---

Rune Jensen wrote:
> Der må så bare være en grund til, den er forældet.

Det må der vel, men indtil nu har jeg ikke læst en, som giver mening i
mit pragmatiske verdensbillede.

HTML5 vil formentlig fastlægge <XMP> (og alle andre elementer), hvilket
må forventes at lede til at alle seriøse webbrowsere i nutid og fremtid
vil vælge at understøtte elementet.

Da elementet således med stor sandsynlighed vil være understøttet til
evig tid og virker strålende den dag i dag er der i mine øjne ingen
grund til ikke at bruge det.

---

"John S. Thomsen" <john.s.thomsen@gmail.com> skrev i en meddelelse
news:47408d5c$0$2103$edfadb0f@dtext02.news.tele.dk...

>> Der må så bare være en grund til, den er forældet.
>
> Det må der vel, men indtil nu har jeg ikke læst en, som giver mening i mit
> pragmatiske verdensbillede.
>
> HTML5 vil formentlig fastlægge <XMP> (og alle andre elementer), hvilket må
> forventes at lede til at alle seriøse webbrowsere i nutid og fremtid vil
> vælge at understøtte elementet.


Ønsketænkning?
Det er jo snart jul...

Er der noget at have det i, så vil jeg godt se et link.

Jeg har lidt svært ved at se, at man skulle genoptage et tag, man allerede
har fjernet.
Jeg mener i øvrigt at XHTML er fremtiden, og at HTML bliver "deprecated".


> Da elementet således med stor sandsynlighed vil være understøttet til evig
> tid og virker strålende den dag i dag er der i mine øjne ingen grund til
> ikke at bruge det.


En lidt besynderlig form for sandsynlighedsregning - i hvert fald indtil de
underliggende påstande er dokumenteret.
Hvis man er ligeglad med om andre kan se ens sider i morgen, kan man da
blive ved med at skrive sine HTML koder som i gamle dage.
Der er da i det hele taget slet ingen grund til at følge med i udviklingen,
hvis man er ligeglad med gældende standarder.


Birger

---

Birger wrote:
> "John S. Thomsen" <john.s.thomsen@gmail.com> skrev i en meddelelse
> news:47408d5c$0$2103$edfadb0f@dtext02.news.tele.dk...
>
>>> Der må så bare være en grund til, den er forældet.
>> Det må der vel, men indtil nu har jeg ikke læst en, som giver mening i mit
>> pragmatiske verdensbillede.
>>
>> HTML5 vil formentlig fastlægge <XMP> (og alle andre elementer), hvilket må
>> forventes at lede til at alle seriøse webbrowsere i nutid og fremtid vil
>> vælge at understøtte elementet.
>
>
> Ønsketænkning?

Godt spørgsmål. For tiden regner jeg med at få ret, men der er
selvfølgelig altid en vis risiko ved at spå om fremtiden.

> Det er jo snart jul...
>
> Er der noget at have det i, så vil jeg godt se et link.

Med hensyn til at <xmp> ikke er fuldstændigt død, borte og glemt, så er
her et link til et indlæg i debatten om den kommende HTML5 specifikation:

http://lists.w3.org/Archives/Public/public-html/2007Aug/0694.html

Bemærk at linket er fra så sent som august 2007. Her et uddrag:

<citat>
IE's behaviour seems slightly useful for <xmp> and <plaintext>, since it
lets you write

<xmp>
<!DOCTYPE HTML>
<title>An example HTML5 document</title>
<p>...
</xmp>

and not get an unexpected blank line at the top.
</citat>

Dette er bare et eksempel på at den kommende HTML5 vil gøre en dyd ud af
at specificere alle elementer entydigt. Hvis man læser "Abstract" på
forsiden af "HTML5 - W3C Working Draft 15 November 2007":

http://www.w3.org/html/wg/html5/#abstract

står der:

"special attention has been given to defining clear conformance criteria
for user agents in an effort to improve interoperability"

Mht understøttelse af <xmp> i nutiden, så ved jeg ikke med Safari, men
de andre store seriøse nutidige ikke-mobile webbrowsere understøtter
elementet.

Mht fremtiden, så har Microsoft tænkt sig lejlighedsvis at fryse IE's
måde at håndtere HTML, hvilket betyder at <xmp> ikke pludselig
forsvinder ud i den blå luft i løbet af de næste mange år.

Microsofts standpunkt kommer f.eks. frem i dette indlæg:

http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html

"I believe our (IE's) only tenable answer (to satisfy the goals of 1)
don't break the web, and 2) improve our standards compliance) is that we
must require that document authors opt in to standards compliance.
....
That means the incorrect behavior is the default!
....
Unfortunately, "standards mode" is too widely adopted now, and we break
too much compatibility if we change our UA behavior there, so its time
has come."

Med andre ord har Microsoft tænkt sig at lade fremtidige udgaver af IE
opfatte "standards mode" som en slags "quirks mode 2".

Med hensyn til Gecko-browsere (Firefox, Flock, SeaMonkey, Epiphany,
....), så tvivler jeg på at Mozilla kunne finde på at droppe support og
hvis det skulle ske, så er det jo tilladt enhver at skrive en patch.

Konklusionen må være, ligemeget hvordan man ser på det, at <xmp> virker
nu og meget lang tid ud i fremtiden.

> Jeg har lidt svært ved at se, at man skulle genoptage et tag, man allerede
> har fjernet.

Måske var grunden til at <xmp> blev fjernet for mange år siden at
elementet ikke er særlig SGML venligt. Jeg kender ikke meget til SGML,
men jeg ved at SGML er en død sild nu i HTML sammenhæng:

HTML Working Group Charter:
http://www.w3.org/2007/03/HTML-WG-charter.html

Hvorfra dette stammer:

"The Group will define conformance and parsing requirements for 'classic
HTML', taking into account legacy implementations; the Group will not
assume that an SGML parser is used for 'classic HTML'."

Her skærers det ud i pap på en meget diplomatisk måde ved at medtage
SGML som en mulighed selv om den mulighed for længst er forkastet af den
virkelige verden.

Hvorvidt <xmp> får genoprejsning tvivler jeg på, men det er ikke
utænkeligt. Hvad vigtigere er, så eksisterer og virker elementet
strålende den dag i dag.

Bemærk i øvrigt formuleringen "taking into account legacy
implementations", som støtter min tro på at <xmp> er kommet for at blive.

> Jeg mener i øvrigt at XHTML er fremtiden, og at HTML bliver "deprecated".

Udsagnet er sjovt i mere end en betydning udover at meget lidt tyder på,
at det kommer til at holde stik.

For det første, så er sagen den at de store browserproducenter har
forkastet XHTML 2. Mozilla (Firefox), Opera og Apple(Safari) gik sammen
om at danne WHATWG tilbage i ... det var vel år 2004 ... Hvilket ledte
til at W3 nedsatte en ny HTMLWG, som nu arbejder på HTML5. Microsoft(IE)
var og er ikke med i WHATWG, men deltager i HTMLWG, hvor Chris Wilson
har følgende at sige om XHTML 2:

"the XHTML 2.0 effort screwed up"

Her er linket, hvor han skriver det:
http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html

Det korte og det lange er, at der ikke er support for XHTML 2 i
virkelighedens webbrowser verden.

For det andet, så er der sket det morsomme, at der nu eksisterer to HTML
Working Groups i W3C. Den ene er "the XHTML 2 Working Group" og den
anden er "the HTML WG". Begge grupper mener de har ret til navnet XHTML:

http://lists.w3.org/Archives/Public/public-html/2007Jun/0450.html

Hvis XHTML2 gruppen får ret, så bliver XHTML ikke en del af fremtiden de
næste mange år, hvis det da overhovedet nogensinde kommer til at ske.

Hvis ikke XHTML2 gruppen får ret, så bliver XHTML navnet på den XML
serialization af HTML som for tiden er kendt som XHTML. Hvis det sker,
så er der ikke noget enten eller mht HTML og XHTML. Så er det et både
og. Begge er fortid, begge er fremtid.

>> Da elementet således med stor sandsynlighed vil være understøttet til evig
>> tid og virker strålende den dag i dag er der i mine øjne ingen grund til
>> ikke at bruge det.
>
>
> En lidt besynderlig form for sandsynlighedsregning - i hvert fald indtil de
> underliggende påstande er dokumenteret.

Det håber jeg så de er nu. Gider nok ikke føre ret meget mere
dokumentation lige foreløbig. Ovenstående blev noget omfangsrigt.

> Hvis man er ligeglad med om andre kan se ens sider i morgen, kan man da
> blive ved med at skrive sine HTML koder som i gamle dage.

Jo flere der bruger HTML koder fra gamle dage jo større incitament har
browserproducenter til at understøtte gamle koder og jo større glæde har
fremtidens internetbrugere af nettets gamle sider.

Endvidere forøger det også sandsynligheden for at mine gætterier
vedbliver med at være sande

---

> Med hensyn til at <xmp> ikke er fuldstændigt død, borte og glemt, så er
> her et link til et indlæg i debatten om den kommende HTML5 specifikation:

Det undrer mig lidt, at der overhovedet tales om HTML 5, da man ellers er
sprunget fra HTML 4 til XHTML 1.
Men nu havde jeg så heller ikke set din dokumentation før.


>> Jeg mener i øvrigt at XHTML er fremtiden, og at HTML bliver "deprecated".
>
> Udsagnet er sjovt i mere end en betydning udover at meget lidt tyder på,
> at det kommer til at holde stik.

Til gengæld er mit indtryk, at der allerede er mange, der er begyndt at
skrive deres kode i XHTML.

Umiddelbart lyder det fint, hvis <xmp> skulle blive gyldigt igen, men på den
anden side, så har den stigende brug af serverside-scripting og CMS-baserede
sider nok overflødiggjort den en del, da man kan nøjes med at skrive &lt;,
&gt; og &amp; én gang for alle i en søg-og-erstat-funktion.

Jeg ville dog begræde, hvis man igen skulle til at skrive html-koder med
upper-case (altså <XMP> i stedet for <xmp>). Det er bare for grimt,
besværligt og tilmed gammeldags i mine øjne. Dét er et levn fra forrige
årtusinde, som selv jeg, der ellers var længe om at gå over til ren html 4,
skrottede næsten fra starten.

---

> Det undrer mig lidt, at der overhovedet tales om HTML 5, da man ellers er
> sprunget fra HTML 4 til XHTML 1.
> Men nu havde jeg så heller ikke set din dokumentation før.

Men interessant læsning i øvrigt.

Det kunne være interessant at høre, hvad de "gamle rotter" i faget har at
sige til denne "tvist" mellem html5- og xhtml-tilhængerne.
Af dit (Johns-) indlæg får jeg nemlig det indtryk, at det er to
rivaliserende grupper indenfor W3Cs rækker, der kæmper for hhv. xhtml 2 og
html 5.

Og den vækker også liv i min gamle undren over, at selv et linieskift skal
afsluttes i xhtml (<br> vs. <br />)
Et linieskift er vel et linieskift.
<br>Læs gerne mellem linierne</br>

---

Philip Nunnegaard wrote:
> Det undrer mig lidt, at der overhovedet tales om HTML 5, da man ellers
> er sprunget fra HTML 4 til XHTML 1.

HTML 4 og XHTML 1 indgår som en del af grundlaget for HTML 5:

"This specification is intended to replace (be the new version of) what
was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications."

Citatet stammer fra HTML 5 - W3C Working Draft 15 November 2007
http://www.w3.org/html/wg/html5/


W3C agiterede i årevis for dette udviklingsforløb:

HTML 4 -> XHTML 1 -> XHTML 2

I praksis kommer det i første omgang til at gå sådan:

HTML 4 + XHTML 1 -> HTML 5

Det er der ikke nogen tvivl om, men for tiden er det en stor blodig
slagmark, hvor forskellige aktører kæmper for at få netop deres sager
igennem.

---

"John S. Thomsen" <john.s.thomsen@gmail.com> skrev i en meddelelse
news:47418f20$0$2087$edfadb0f@dtext02.news.tele.dk...
> Philip Nunnegaard wrote:
>> Det undrer mig lidt, at der overhovedet tales om HTML 5, da man ellers er
>> sprunget fra HTML 4 til XHTML 1.
>
> HTML 4 og XHTML 1 indgår som en del af grundlaget for HTML 5:
>
> "This specification is intended to replace (be the new version of) what
> was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications."
>
> Citatet stammer fra HTML 5 - W3C Working Draft 15 November 2007
> http://www.w3.org/html/wg/html5/
>
>
> W3C agiterede i årevis for dette udviklingsforløb:
>
> HTML 4 -> XHTML 1 -> XHTML 2
>
> I praksis kommer det i første omgang til at gå sådan:
>
> HTML 4 + XHTML 1 -> HTML 5
>
> Det er der ikke nogen tvivl om, men for tiden er det en stor blodig
> slagmark, hvor forskellige aktører kæmper for at få netop deres sager
> igennem.


Har vist ikke fået hele denne post...

Hvis der ikke er nogen tvivl, hvorfor så en blodig slagmark - der er jo ikke
noget at slås om...
Glædelig jul - måske får du hvad du ønsker dig.

Du refererer et dokumentation under udvikling - flere steder understreges at
det ikke er færdigt, stadig under udvikling og stadig diskuteres.
"Implementors should be aware that this specification is not stable.
Implementors who are not taking part in the discussions are likely to find
the specification changing out from under them in incompatible ways. Vendors
interested in implementing this specification before it eventually reaches
the Candidate Recommendation stage should join the aforementioned mailing
lists and take part in the discussions."
Ikke desto mindre, er du i stand til at konkludere hvordan fremtiden
bliver - hvad alle disse intelligente mennesker ender med at blive enige om.
Hvorfor fortæller du dem ikke bare, hvordan du har vedtaget det vil blive?
Sikken masse tid, spildt arbejde og ærgrelser, du kunne spare dem for!


Jeg foretrækker at hold mig til det jeg ved.

Birger

---

"John S. Thomsen" <john.s.thomsen@gmail.com> skrev i en meddelelse
news:4740d385$0$2108$edfadb0f@dtext02.news.tele.dk...

> http://lists.w3.org/Archives/Public/public-html/2007Aug/0694.html

At nogen bekymrer sig om hvordan deprecated tags vises i eksiterende
browsere, er da prisværdigt - men kan næppe bruges som argument for, at
disse tags vil blive genoptaget i fremtidige standarder.
(man kunne også hæfte sig ved, at den eneste browser, der ser ud til at
kunne håndtere <xmp> i denne oversigt er IE7.)

> http://www.w3.org/html/wg/html5/#abstract

Der findes ingen definition af <xmp>. Derimod beskrivelser af hvordan man
vil forvente en browser håndterer indholdet, hvis det alligevel optræder i
HTML5. ("breaking the web")

> http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html

Nu handler det ikke ret meget om IE, men en hel del om standarder.
Ovenstående artikel handler - som jeg læser den - netop om visning af sider
der ikke overholder standarderne. Backward compatibility. (Og så om de
problemer/overvejelser M$ har haft i den anlending)
<xmp> er ikke en del af nuværende standarder.
Alligevel er der nogen der bliver ved at anvende det (og andre deprecated)
tag - og samtidig forventer at browsere skal vise dokumentet i henhold til
standarderne.
Der er intet i ovenstående artikel, der handler om <xmp>, og fremtidig
understøttelse eller ej.

> Konklusionen må være, ligemeget hvordan man ser på det, at <xmp> virker nu
> og meget lang tid ud i fremtiden.

Nej. Man kan gætte på at et tag der ligner <xmp> bliver en del af en
fremtidig standard.
I øjeblikket er det en kendsgerning, at det ikke er en del af standarderne.
At det virker, skyldes udelukkende venlighed og browsere's tilbøjelighed til
at tilgive fejl - ønsket om ikke at "break the web".

> http://www.w3.org/2007/03/HTML-WG-charter.html

SGML - Standard Generalized Markup Language - er et markup sprog med sin
egen berettigelse og anvendelse.
Det er svjv. det mest komplekse af dem.
Måske derfor man har forsøgt (og bruger) SGML parsere, til at validere de
mindre komplekse (HTML, XHTML etc.).
SGML har ikke noget med HTML at gøre - bortset fra at begge er skrevet som
markup sprog, og derfor har visse ligheder.

> "The Group will define conformance and parsing requirements for 'classic
> HTML', taking into account legacy implementations; the Group will not
> assume that an SGML parser is used for 'classic HTML'."
>
> Her skærers det ud i pap på en meget diplomatisk måde ved at medtage SGML
> som en mulighed selv om den mulighed for længst er forkastet af den
> virkelige verden.

Hvad skæres ud i pap?
At SGML og HTML er forskellige sprog, har altid været sådan.
Brugen af SGML parsere til at validere HTML, har altid været
"behagelighed" - ønsket om ikke at skulle skrive en parser specifikt til
HTML, men bruge allerede eksisterende..
Der står, at man ikke vil forlange at parsing foretages af en SGML parser.
Altså lades alle døre åbne, og absolut ingenting skæres ud i pap.
Så vidt jeg ved, er W3C's validation service baseret på en SGML parser - som
altså er alt andet end forkastet af den virkelige verden, men tværtimod i
brug op til mange gange dagligt...
Måske mener du selve sproget SGML. Det kan jeg ikke forestille mig, at en
gruppe der behandler HTML overhovedet vil udtale sig om.

Og det har stadig ikke noget med <xmp> at gøre.

> "the XHTML 2.0 effort screwed up"
- er en - i denne forbindelse, vigtig - persons mening. Ikke en konstateret
kendsgerning.

> http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html

Samme link som tidligere.
Det handler stadig ikke om IE, men om standarder, overholdelse af samme, og
gætterier der fremlægges som kendsgerninger.

> http://lists.w3.org/Archives/Public/public-html/2007Jun/0450.html

>>> Da elementet således med stor sandsynlighed vil være understøttet til
>>> evig tid og virker strålende den dag i dag er der i mine øjne ingen
>>> grund til ikke at bruge det.

Det ER ikke understøttet af seneste standarder. Og der er INTET i
ovenstående der indikerer at det bliver det i fremtidige...

> Jo flere der bruger HTML koder fra gamle dage jo større incitament har
> browserproducenter til at understøtte gamle koder og jo større glæde har
> fremtidens internetbrugere af nettets gamle sider.

Jeg mener nu, at hvis man vil deltage konstruktivt i udviklingen af
standarderne, er den rigtige vej, at gå ind i arbejdet.
At vedblive at bruge deprecated tags i ren trods, er nærmere undergravning
af W3C's arbejde.
At præsentere gætterier, som var de dokumenterede kendsgerninger, og derved
lede andre på vildspor, hjælper hverken dem du vildleder eller dig selv, og
får ikke W3C til at ændre synspunkter.

> Endvidere forøger det også sandsynligheden for at mine gætterier vedbliver
> med at være sande

Næppe.
Jeg vil ikke udtale mig om fortiden - ved ikke hvor mange gange du har
"gættet rigtigt".
Her har du omtrent samme chance, som at slå plat eller krone.



Ellers interessant læsning.

Som det fremgår, er jeg hverken enig i dine fortolkninger eller gætterier.

"HTML5 vil formentlig fastlægge <XMP> (og alle andre elementer), hvilket
må forventes at lede til at alle seriøse webbrowsere i nutid og fremtid
vil vælge at understøtte elementet."

Nej. HTML5 vil MÅSKE fastlægge et element der ligner eller kan gøre det
samme som <xmp>... og understøttelse i al fremtid, ville være herligt - men
næppe noget man skal sætte for meget lid til.

"Da elementet således med stor sandsynlighed vil være understøttet til
evig tid og virker strålende den dag i dag er der i mine øjne ingen
grund til ikke at bruge det."

Med al mulig respekt, ser det ikke for mig ud somom nogen overhovedet, kan
udtale sig om sandsynligheder for hverken det ene eller andet, hvad angår
HTML5, XHTML eller fremtidig validitet af tags.

Du refererer igangværende diskussioner af mulighederne - diskussioner som
ikke er slut, om emner der ikke er taget endelig stilling til endnu.
Det er IMHO et meget løst grundlag at spå på - og specielt at fremlægge
disse gætterier, som var de en endegyldig sandhed.
(Og det uanset om man er enig med den ene eller den anden.)


Jeg vil gøre opmærksom på, at jeg er ikke nødvendigvis uenig i dine ønsker
og gætterier.
Til gengæld er jeg meget uenig i din fremlægning af disse teorier som var de
kendsgerninger.


Birger

---

Birger wrote:
> http://msdn2.microsoft.com/en-us/library/ms535919.aspx

På dette link står at læse:

"This object is a Microsoft extension to HTML"

> <xmp> virker så - formentlig - kun i IE.

Det kan man foranlediges til at tro, men <xmp> var at finde i HTML flere
år før den første udgave at IE så dagens lys i år 1995.



I HTML 1.2 WD fra Juni 1993 står:

<!ELEMENT XMP - - CDATA>

specifies that the following text is a legal XMP element:

<xmp>Here's an example. It looks like it has
<tags> and <!--comments-->
in it, but it does not. Even this
</ is data.</xmp>



I HTML 2.0 hedder det:

5.5.2.1. Example and Listing: XMP, LISTING

The <XMP> and <LISTING> elements are similar to the <PRE> element,
but they have a different syntax. Their content is declared as CDATA,
which means that no markup except the end-tag open delimiter-in-
context is recognized (see 9.6 "Delimiter Recognition" of [SGML]).

> Fra HTML 3.2 hedder det <pre> eller <samp>
>
> Og fra HTML 4 fremad, eksisterer disse tags vist ikke længere.

I dagens anledning har jeg lige checket, at det også virker i Firefox,
Opera og Konqueror.

Altså eksisterer elementet

---

>> <xmp> virker så - formentlig - kun i IE.
>
> Det kan man foranlediges til at tro, men <xmp> var at finde i HTML flere
> år før den første udgave at IE så dagens lys i år 1995.

Spørgsmålet er måske mere, om det _stadig_ er gangbart.


> I dagens anledning har jeg lige checket, at det også virker i Firefox,
> Opera og Konqueror.
>
> Altså eksisterer elementet

Ikke nødvendigvis.
Men det _virker_ åbenbart stadig.
Dog validerer det ikke. (Har lige testet det).

---

Philip Nunnegaard wrote:
> Men det [xmp] _virker_ åbenbart stadig.
> Dog validerer det ikke. (Har lige testet det).

Det vigtige for mig er at det virker

Elementet er faktisk meget nyttigt, når man laver små eksempler (til sig
selv). Jeg bruger ofte strukturen:

/* html her */
<xmp>
/* html gentaget her */
</xmp>

Eksempel:

<!DOCTYPE html>
<h1><center>Hello</center></h1>
<xmp>
<!DOCTYPE html>
<h1><center>Hello</center></h1>
</xmp>

---

> Det vigtige for mig er at det virker

Én ting er alle de unoder og dårlige vaner, vi har, når vi skriver
html-kode.
En anden ting er, at det nok ikke er nogen god idé at lære disse fejl fra
sig uden i det mindste at gøre opmærksom på, at det ikke er "korrekt".

---

"John S. Thomsen" <john.s.thomsen@gmail.com> skrev i en meddelelse
news:473f9739$0$2102$edfadb0f@dtext02.news.tele.dk...
> Rune Jensen wrote:

>> Ja - men en helt legitim grund er referering af kode. Her kan det ikke
>> undgås.
>
> Sludder og vrøvl. Det kan sagtens undgås; se nederst i dette indlæg.
[SNIP]
> Det kan du gøre. Så kan vi andre bruge xmp-elementet:
>
> <xmp>
> <label for="homepage">Hjemmeside:</label>
> </xmp>

<xmp> er forældet, se:
http://www.w3schools.com/tags/tag_pre.asp

Jeg har ikke kunnet se, at <samp> skulle kunne gøre det samme som
ovenstående:
http://www.w3schools.com/tags/tag_phrase_elements.asp

....og ja, jeg fortsætter med at bruge HTMLencode. Den funktion er
uundværlig


MVH
Rune Jensen

---

Philip Nunnegaard skrev:

> Vil det sige, at det i princippet er i orden (valid html) at skrive æ, ø og
> å i stedet for &aelig;, &oslash; og &aring;?

Ja, lige præcis. Man skal jo erklære et tegnsæt så browseren ved
hvordan den skal tolke koderne, og ISO-8859-1 (det hidtil normale
valg) og UTF-8 (den kommende standard) omfatter begge to de
danske tegn.

> Jeg ved godt, at I ikke vil anbefale det

Jeg vil i højeste grad anbefale det, og jeg vil i højeste grad
fraråde at bruge &-koderne for de danske bogstaver. Det fylder og
ser tosset ud i koden.

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

---

Bertel Lund Hansen <unospamo@lundhansen.dk> writes:

> Det er kun &, < og > der behøver kodes på en normal
> dansk hjemmeside.

Afhængigt af hvad man mener med "normal dansk hjemmeside", så er
det måske endda kun "&" og "<" der behøver det. I almindelig tekst
i HTML-elementer behøver man ikke kode ">".

Hvis man har sjove ting stående i *attributter*, så skal ">", "'" og
""" måske også kodes.

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

---

Lasse Reichstein Nielsen skrev:

> Afhængigt af hvad man mener med "normal dansk hjemmeside", så er
> det måske endda kun "&" og "<" der behøver det. I almindelig tekst
> i HTML-elementer behøver man ikke kode ">".

Det er nok nemmere at huske at kode dem begge.

> Hvis man har sjove ting stående i *attributter*, så skal ">", "'" og
> """ måske også kodes.

Det kan som regel undgås ved kløgtig brug af enkelte eller dobbelte
anførselstegn. Eksempel:

   <img src='windows1252.jpg' alt="Windows' specifikke tegnsæt sutter!">.

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

---

"Birger" <sdc@bbsorensen.com> writes:

> "Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i en meddelelse
> news:47357107$0$15878$edfadb0f@dtext01.news.tele.dk...
>> Vil det sige, at det i princippet er i orden (valid html) at skrive æ, ø
>> og å i stedet for &aelig;, &oslash; og &aring;?
>> Jeg ved godt, at I ikke vil anbefale det, men jeg har godt nok studset
>> over, at jeg ikke har fået fejlmeldinger på dén konto.

> Philip : Det kommer an på charset. ISO-8859-1 forstår de danske karakterer -
> tror ikke der er så amnge andre der gør det.

Der er også iso-8859-15 (lige som ..-1, bare med euro-tegn),
windows-1252, hvor æ, ø og å har samme talkode som i iso-8850-1, og
der er Unicode, kodet enten som utf-8 eller utf-16, hvor de danske
tegn kodes som to-byte- sekvenser. Unicode-kodning skal man lade ens
editor eller serverside-processor om at styre.

/L '"rå tekst" findes ikke!'
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen skrev:

> windows-1252, hvor æ, ø og å har samme talkode som i iso-8850-1

Undgå for enhver pris Windows' specifikke kodetabeller. De virker
kun på én slags systemer.

Anyone who slaps a "this page is best viewed with Browser X"
label on a Web page appears to be yearning for the bad old days,
before the Web, when you had very little chance of reading a
document written on another computer, another word processor, or
another network.

- Tim Berners-Lee in Technology Review, July 1996

Det samme gælder dem der klasker en windows-1252 på som tegnsæt.

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

---

Bertel Lund Hansen <unospamo@lundhansen.dk> writes:

> Lasse Reichstein Nielsen skrev:
>
>> windows-1252, hvor æ, ø og å har samme talkode som i iso-8850-1
>
> Undgå for enhver pris Windows' specifikke kodetabeller. De virker
> kun på én slags systemer.

Nej, de virker skam fint på andre systemer også.

Windows-1252 er registreret ved IANA og understøttes af alle moderne
browsere på lige fod med iso-8859-tegnsættene og utf-8/16.
Når først man kører Unicode internt, og det bliver browsere nødt til,
så er tilføjelsen af en ekstra kodning helt banal.

Det der måske kan give problemer er at bruge de tegn der ligger
i intervallet 128 til 159, og hvor windows-1252 adskiller sig fra
iso-8859-1. Hvis den font man bruger ikke har de tegn, så kan den
ikke vise dem. Det er noget der skal løses lokalt på klienten.
Der er tilgængelige fonte der har alle tegn med.
Det problem ændrer sig ikke ved at man bruger UTF-8-kodning af
de samme tegn.

En hurtig test i Firefox på Ubuntu giver ingen problemer med at
vise alle synlige windows-1252-tegn i en HTML-side med den kodning.

<URL:http://www.infimum.dk/privat/charsetTest1252.html>
<URL:http://www.infimum.dk/privat/UbuntuFirefox.png>
(ok, der er en fejl i HTML'en, men jeg efterlader den så den
passer med billedet :)

> Det samme gælder dem der klasker en windows-1252 på som tegnsæt.

Test det.

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

---

Lasse Reichstein Nielsen skrev:

> Nej, de virker skam fint på andre systemer også.

Det ændrer ikke min holdning. Det er en uskik at en person
opfinder sin egen 'standard'. Jeg har brugt oceaner af tid på at
slås med DOS' og Windows' interne tegnsæt, og jeg kan kun
anbefale at man glemmer at de nogen sinde har eksisteret.

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

---

Bertel Lund Hansen wrote:

> Jeg har brugt oceaner af tid på at
> slås med DOS' og Windows' interne tegnsæt, og jeg kan kun
> anbefale at man glemmer at de nogen sinde har eksisteret.

Åh nej Bertel, du giver mig mareridt!
Nu havde jeg lykkelig glemt EBCDIC,Roman8,ISO,PC8,PC8DN,CP 437,CP 850,
CP865...
Gå væk billeder!

--
Med venlig hilsen
Stig Johansen

---

"
"Rune Jensen" <runeofdenmark@hotmail.com> writes:

> Anyway, hvis man kigger på, hvordan alle andre gør, så kan man se, de fleste
> også encoder HTML, når der skal vises meget kode. Specielt, hvis det er CMS
> kan jeg ikke se, det kan betale sig andet, når HTMLencode funktionen er
> gratis, og man kan se, den virker.
>
> Dog kan jeg godt se, det ikke er nødvendigt at encode " , det ved jeg ikke
> hvorfor man gør, hvis det sættes i <pre> og <code>

Måske netop fordi man har en gratis HTMLencode-funktion der ikke tager
højde for hvor resultatet skal bruges. Hvis det skal stå i en attribut,
så skal ">" og det tegn man bruger omkring attribut-teksten, også kodes.
Det er så sikkert gåseøjnene.

Et suspekt eksempel:
<img src="sourcecode.png" alt="&lt;img src=&quot;sourceode.png&quot;&gt;">

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

---

"Rune Jensen" <runeofdenmark@hotmail.com> writes:

> ...og ja, jeg fortsætter med at bruge HTMLencode. Den funktion er
> uundværlig

Hvis man alligevel kode HTML for at vise det, hvad så med at lave
noget HTML der er farvelagt og lækkert :)

Jeg har lavet det her offline
<URL:http://www.infimum.dk/HTML/multiselect.html#ExNoLSE>
men jeg er sikker på at der også er server-side-biblioteker der kan
lave noget lignende.
<URL:http://www.vwd-cms.com/examples/CodeViewer/Example1.aspx>
(tilfældigvis til ASP, og viser at man ikke nødvendigvis skal stole på
udviklerens farversans :)

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

---

"Lasse Reichstein Nielsen" skrev...
> "Rune Jensen" writes:
>
>> ...og ja, jeg fortsætter med at bruge HTMLencode. Den funktion er
>> uundværlig
>
> Hvis man alligevel kode HTML for at vise det, hvad så med at lave
> noget HTML der er farvelagt og lækkert :)

Du siger noget. Jeg tager lige et par kig på de koder dér. Ser godt nok ud
til, den kun virker til .net, men må da findes noget til VBscript

Ellers pløkker jeg sgi én selv sammen...


MVH
Rune Jenen

---

"John S. Thomsen" <john.s.thomsen@gmail.com> writes:

> Det vigtige for mig er at det virker
>
> Elementet er faktisk meget nyttigt, når man laver små eksempler (til
> sig selv). Jeg bruger ofte strukturen:
....
> Eksempel:
>
> <!DOCTYPE html>
> <h1><center>Hello</center></h1>
> <xmp>
> <!DOCTYPE html>
> <h1><center>Hello</center></h1>
> </xmp>

Det er så ikke engang gyldigt HTML 2.
Du refererede selv specifikationen, og et XMP-element afsluttes af
et end-tag-open ("in context", hvad det så end betyder), og det
vil sige at xmp-elementet slutter ved </ i </center>.

Det er det samme problem der er med <script>-elementer. Det er ikke
korrekt at skrive:
<script type="text/javscript">
document.write("<p>test</p>");
</script>
fordi script-elementet slutter ved </p>.

Browsere er mere tilgivende end standarder, så de gætter nok på at
du mente at slutte ved </xmp> (og </script>), men det betyder ikke
at det er rigtigt, blot at browsernes fejl-korrektion virker.

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

---

Lasse Reichstein Nielsen wrote:
> "John S. Thomsen" <john.s.thomsen@gmail.com> writes:
>
>> <!DOCTYPE html>
>> <h1><center>Hello</center></h1>
>> <xmp>
>> <!DOCTYPE html>
>> <h1><center>Hello</center></h1>
>> </xmp>
>
> Det er så ikke engang gyldigt HTML 2.
> Du refererede selv specifikationen, og et XMP-element afsluttes af
> et end-tag-open ("in context", hvad det så end betyder), og det
> vil sige at xmp-elementet slutter ved </ i </center>.

Jeg læser specifikationen sådan at "in context" betyder at xmp skal
følge efter end-tag-open, dvs </xmp> er en gyldig afslutning, mens
</center> ikke er det. Konteksten er xmp-elementet.

---

"John S. Thomsen" <john.s.thomsen@gmail.com> writes:

> Jeg læser specifikationen sådan at "in context" betyder at xmp skal
> følge efter end-tag-open, dvs </xmp> er en gyldig afslutning, mens
> </center> ikke er det. Konteksten er xmp-elementet.

Jeg er temmelig sikker på at det ikke er det det betyder.
Lad mig se om jeg kan finde noget der underbygger det.

Ham her siger noget:
<URL:http://xml.coverpages.org/senguptaRCDATA.html>
Her er noget mere abstrakt:
<URL:http://www.is-thought.co.uk/book/sgml-4.htm>
Se specielt figur 4.5. Konteksten er SGML-typen man kigger på.
ETAGO er en delimiter i konteksten af "XMP" elementets indhold,
som jeg tror er SGML-konteksten CON.
Det er "ETAGO" (altså bare "</") der afgrænser CDATA-indholdet,
uafhængigt af hvad der står bagefter.

Og så er der selvfølgelig HTML 2-specifikationen (RFC 1866):
---
5.5.2.1. Example and Listing: XMP, LISTING

The <XMP> and <LISTING> elements are similar to the <PRE> element,
but they have a different syntax. Their content is declared as CDATA,
which means that no markup except the end-tag open delimiter-in-
context is recognized (see 9.6 "Delimiter Recognition" of [SGML]).

NOTE - In a previous draft of the HTML specification, the syntax
of <XMP> and <LISTING> elements allowed closing tags to be treated
as data characters, as long as the tag name was not <XMP> or
<LISTING>, respectively.
---
Som noten siger, så var det rigtigt i et tidligere udkast, men er det altså
ikke mere.
De fortsætter også:
---
Since CDATA declared content has a number of unfortunate interactions
with processing techniques and tends to be used and implemented
inconsistently, HTML documents should not contain <XMP> nor <LISTING>
elements -- the <PRE> tag is more expressive and more consistently
supported.
---
Så ja, det fandtes, men det var frarådet allerede dengang.
<URL:http://rfc.sunsite.dk/rfc/rfc1866.html>

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

---

Lasse Reichstein Nielsen wrote:
> "John S. Thomsen" <john.s.thomsen@gmail.com> writes:
>
>> Jeg læser specifikationen sådan at "in context" betyder at xmp skal
>> følge efter end-tag-open, dvs </xmp> er en gyldig afslutning, mens
>> </center> ikke er det. Konteksten er xmp-elementet.
>
> Jeg er temmelig sikker på at det ikke er det det betyder.

Det er jeg også efter at have læst det du skriver herunder.

> Lad mig se om jeg kan finde noget der underbygger det.
>
> Ham her siger noget:
> <URL:http://xml.coverpages.org/senguptaRCDATA.html>
> Her er noget mere abstrakt:
> <URL:http://www.is-thought.co.uk/book/sgml-4.htm>
> Se specielt figur 4.5. Konteksten er SGML-typen man kigger på.
> ETAGO er en delimiter i konteksten af "XMP" elementets indhold,
> som jeg tror er SGML-konteksten CON.
> Det er "ETAGO" (altså bare "</") der afgrænser CDATA-indholdet,
> uafhængigt af hvad der står bagefter.

Jeg har kigget lidt mere på sagen. Her følger først noget info:

I HTML 3.2 står der:

<![ %HTML.Deprecated [

<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->

<!ELEMENT (XMP|LISTING) - - %literal>
<!ELEMENT PLAINTEXT - O %literal>

]]>

og i HTML 5 - W3C Working Draft 15 November 2007 står der:

"While the HTML form of HTML5 bears a close resemblance to SGML and XML,
it is a separate language with its own parsing rules.

Some earlier versions of HTML (in particular from HTML2 to HTML4) were
based on SGML and used SGML parsing rules. However, few (if any) web
browsers ever implemented true SGML parsing for HTML documents; the only
user agents to strictly handle HTML as an SGML application have
historically been validators. The resulting confusion — with validators
claiming documents to have one representation while widely deployed Web
browsers interoperably implemented a different representation — has
wasted decades of productivity. This version of HTML thus returns to a
non-SGML basis."

Herfra slutter jeg, at du har ret i din tidligere påstand:

"Det er så ikke engang gyldigt HTML 2."

om følgende dokument:

<!DOCTYPE html>
<h1><center>Hello</center></h1>
<xmp>
<!DOCTYPE html>
<h1><center>Hello</center></h1>
</xmp>

men at udsagnet ikke kommer til at gælde for den kommende HTML5
specifikation, idet den ikke længere strengt følger SGML parsing rules,
som i øvrigt er mig stort set ukendte.

Konklusion:

Eksemplet er ikke gyldigt HTML2, men det er gyldigt HTML5

---

"Birger" <sdc@bbsorensen.com> writes:

> Skal man skrive HTML så koden ses på siden, er en anden mulighed at sætte
> den i et textarea - der bliver det ikke fortolket.

Desværre. Igen er det nok browsernes fejlkorrektion der får det til at
se sådan ud, men indholdstypen på textarea er PCDATA. Det betyder at
der ikke må være tags i den. Man skal stadig kode sine "<"'er og "&"'er.

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

---

Den 18-11-07 23.24 skrev Lasse Reichstein Nielsen følgende:
> "Birger" <sdc@bbsorensen.com> writes:
>
>> Skal man skrive HTML så koden ses på siden, er en anden mulighed at sætte
>> den i et textarea - der bliver det ikke fortolket.
>
> Desværre. Igen er det nok browsernes fejlkorrektion der får det til at
> se sådan ud, men indholdstypen på textarea er PCDATA. Det betyder at
> der ikke må være tags i den. Man skal stadig kode sine "<"'er og "&"'er.

Jeg skulle lige til at skrive, at validatoren sluger det fint. Jeg har
selv brugt textarea til at skrive tags uden at kode dem, og den
pågældende side validerer. Men så kom jeg til at kigge i kildekoden,
hvor taggene netop er kodet.

Jeg henter teksten fra en MySQL-database, hvor jeg kan se, at taggene
også er kodet. Mig bekendt har jeg ikke gjort noget for at få dem kodet,
så der må vel være en funktion i php/MySQL, der koder taggene.

--
Mvh. Kim Ludvigsen
Polimiken - en levende netavis, der tør, hvor selv Ekstra Bladet tier.
http://polimiken.dk

---

"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> writes:

>> Med hensyn til at <xmp> ikke er fuldstændigt død, borte og glemt, så
>> er her et link til et indlæg i debatten om den kommende HTML5
>> specifikation:
>
> Det undrer mig lidt, at der overhovedet tales om HTML 5, da man ellers
> er sprunget fra HTML 4 til XHTML 1.

Jeg tror problemet var at specifikationsgruppen sprang, men browserne
blev stående.

Der kom aldrig et overbevisende argument for at XHTML var bedre end
HTML. Til almindelige mennesker der skriver HTML i hånden er HTML
mere tilgivende og nemmere at forstå (jf <br/>). Til andre, der bruger
frameworks til at bygge siden, er det fuldstændig ligegyldigt om man
genererer HTML eller XHTML. Hvis XHTML er en fordel på serveren, fordi
den er nemmere at processere, så kan man trivielt lave den om til HTML
før man sender den til browseren. Og så understøtter IE ikke XHTML
ordentligt, hvilket nok var dødsstøddet.

> Til gengæld er mit indtryk, at der allerede er mange, der er begyndt
> at skrive deres kode i XHTML.

Det er der. Og IE forstår det stadig ikke, så det bliver behandlet som
HTML/Tagsoup alligevel.

> Jeg ville dog begræde, hvis man igen skulle til at skrive html-koder
> med upper-case (altså <XMP> i stedet for <xmp>). Det er bare for
> grimt, besværligt og tilmed gammeldags i mine øjne.

Nogle vil sige at det gør det mere læseligt, men de trænger nok bare
til en editor med farvelægning.
Det har nu heller aldrig været nødvendigt. HTML er ikke case-sensitivt,
så man har altid kunnet skrive det med småt. Jeg har ikke et problem
med at man har valget.
Hvis man skriver HTML i hånden, så er det for åndsvagt at browsere
nægter at forstå at <BR> betyder break, når det nu er åbnelyst hvad
man mente.
HTML mangler på sin vis en compiler: en oversætter fra et accepterende
sprog der forsøger at indrette sig efter at det er mennesker der
skriver, til et strengt og utilgivende computerfortolket format.
HTML (og specielt XML/XHTML) er slet ikke egnet til at blive skrevet
af mennesker.

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

---

> Der kom aldrig et overbevisende argument for at XHTML var bedre end
> HTML. Til almindelige mennesker der skriver HTML i hånden er HTML
> mere tilgivende og nemmere at forstå (jf <br/>).

Hvilket også var grunden til, at jeg først selv hoppede over for nylig, selv
om XHTML så vidt jeg ved har eksisteret siden 1999.
Uenighederne sammen med ovenstående kan måske også forklare, at der ikke er
kommet væsentlige nye standarder til siden da?

---

On Thu, 08 Nov 2007 01:10:12 -0800, Senga <dea_dh@yahoo.com> wrote:

>Siden fyn.netvaerk.org vil ikke validere. Jeg har rettet de fejl, jeg
>forstår. Men en makker har hjulpet mig på nogle områder, og disse fejl
>tør jeg ikke pille ved uden jeres accept :)
>
>De fleste fejl er i denne stil:
>
> Line 21, Column 23: general entity "subpage" not defined and no
>default entity .
><a href="?page=forside&subpage=kommentar">Feedback<span>

<a href="?page=forside&amp;subpage=kommentar">Feedback<span>

& -> &amp;

>validatoren ser gerne, at jeg brugere flere ";" ... men hvor og
>hvordan skal de placeres?

Den fejl forsvinder også, når du retter ovenstående.

>Desuden er et tilbagevendende problem, at jeg har flere id="menu". Det
>skyldes, at jeg også har styles på li og ul i menu. Jeg har prøvet at
>lave den til class i stedet for id, men så virker designet ikke mere.

I stedet for at sætte <ul id="menu">, skal du definere ul-stylingen i
CSS således:
#menu ul { whatever }
- altså en ul inden i den div, der har id="menu"

Good luck!

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

---

Tak hvor er I bare gode :)

Jeg havde ellers prøvet at lave om til class før - også i stylesheet,
men det virker åbenbart bedst med jeres velsignelse :)