mboost-dp1
unknown
7. Once you've practised enough, coding pages becomes a whole lot simpler and faster than any table/tr/td tagsoup
Jeg keder mig og har lige fundet ud af at jeg kan lave et centreret html-table med én celle, bestående af i alt 64 tastetryk, på knap 8 sekunder - og så skal jeg lære noget helt nyt?
Så længe man ikke kan lave noget i xhtml, som jeg ikke kan lave i html, skifter jeg ikke. Den virkelige "grund" til at skifte, er vel hvis der er behov for det. Jeg har kodet html i 4 år, så det sidder sku' i fingrene. Havde jeg ingen erfaring, ville jeg nok vælge xhtml.
If it ain't broken, don't fix it.
Jeg keder mig og har lige fundet ud af at jeg kan lave et centreret html-table med én celle, bestående af i alt 64 tastetryk, på knap 8 sekunder - og så skal jeg lære noget helt nyt?
Så længe man ikke kan lave noget i xhtml, som jeg ikke kan lave i html, skifter jeg ikke. Den virkelige "grund" til at skifte, er vel hvis der er behov for det. Jeg har kodet html i 4 år, så det sidder sku' i fingrene. Havde jeg ingen erfaring, ville jeg nok vælge xhtml.
If it ain't broken, don't fix it.
#5
Alt (x)html som ikke har application/xml+xhtml som content-type bliver alligevel parset som html 4. Så hvis du nøjes med html 4.01 strict, så er det fint fint ;).
XHTML giver dig nogle flere muligheden inden for CSS/JS, og er mere striks på nogle punkter.
Det er dog meste på det teoretisk plan, da nogle browsere (Peger på M$ IE, *IE gemmer sig*) ikke kan følge med udviklingen.
Alt (x)html som ikke har application/xml+xhtml som content-type bliver alligevel parset som html 4. Så hvis du nøjes med html 4.01 strict, så er det fint fint ;).
XHTML giver dig nogle flere muligheden inden for CSS/JS, og er mere striks på nogle punkter.
Det er dog meste på det teoretisk plan, da nogle browsere (Peger på M$ IE, *IE gemmer sig*) ikke kan følge med udviklingen.
Jeg synes nu at alle "burde" anvende de nye stadnarder der kommer fra W3C. (alle punkter herunder kommer fra kunder der kører med IE eller gamle browsere)
1. Det giver bedre cross-browser kompabilitet, da kunderne klager over "dårlige" hp's.
2. Da "firmaer"'erne kæmper om at være dem der understøtter standarden bedst.
Ovenstående giver bedre understøttelse.
3. "if it ain't broken don't fix it" er forældet, programmer bliver aldrig, _aldrig_ repareret nuomdage kun forbedret. Derfor er ordlyden nu "forbedring af", med mindre der self er tale om en helt ny version som fx. XHTML v2.0 .
Jeg bibeholder min tro på at internettet om nogle få år (1-3 år) bliver et håndgribeligt medie få selv den mest amatøragtige der kan finde på at kaste sig ud i XHTML-kodning,
Indtil da, må vi andre nøjes med at tjene penge på de andres uvidenhed...
- Just my $5.25
1. Det giver bedre cross-browser kompabilitet, da kunderne klager over "dårlige" hp's.
2. Da "firmaer"'erne kæmper om at være dem der understøtter standarden bedst.
Ovenstående giver bedre understøttelse.
3. "if it ain't broken don't fix it" er forældet, programmer bliver aldrig, _aldrig_ repareret nuomdage kun forbedret. Derfor er ordlyden nu "forbedring af", med mindre der self er tale om en helt ny version som fx. XHTML v2.0 .
Jeg bibeholder min tro på at internettet om nogle få år (1-3 år) bliver et håndgribeligt medie få selv den mest amatøragtige der kan finde på at kaste sig ud i XHTML-kodning,
Indtil da, må vi andre nøjes med at tjene penge på de andres uvidenhed...
- Just my $5.25
Ifl. W3C er XHTML 2.0 faktisk bagud kompatibel, bare på en anden måde end man er vant til...
#6 - Semantisk markup? Det er nu også muligt at lave med HTML; XHTML er reelt blot et subset af HTML, hvor der hovedsageligt er skåret lidt "presentational markup" væk, og som kræver dokumenter er well-formed.
#7 - Det er jo direkte forkert -- men hvis dokumenterne bliver sendt som text/html, laver Firefox, Opera m.fl. ikke DOCTYPE-sniffing, nej. Validatoren kræver dog stadigvæk betydeligt mere af XHTML-dokumenter, fx validerer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><TiTLe>Jeg er HTML</title>Hejsa<select><option selected></select></body>
som et HTML 4.01 Strict dokument...
Hvilke ekstra muligheder giver XHTML dig mht. CSS og JS??
Og at IE <= v.7 ikke 'forstår' XHTML, gør da absolut ikke XHTMLs fordele teoretiske...
Mange af de ting der bliver nævnt i ranten, er fuldstændig irrelevante ift. hvorvidt man bør vælge XHTML frem for HTML.
('For the record', så er jeg dog en stor fortaler for at man bruger XHTML!)
#6 - Semantisk markup? Det er nu også muligt at lave med HTML; XHTML er reelt blot et subset af HTML, hvor der hovedsageligt er skåret lidt "presentational markup" væk, og som kræver dokumenter er well-formed.
#7 - Det er jo direkte forkert -- men hvis dokumenterne bliver sendt som text/html, laver Firefox, Opera m.fl. ikke DOCTYPE-sniffing, nej. Validatoren kræver dog stadigvæk betydeligt mere af XHTML-dokumenter, fx validerer
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><TiTLe>Jeg er HTML</title>Hejsa<select><option selected></select></body>
som et HTML 4.01 Strict dokument...
Hvilke ekstra muligheder giver XHTML dig mht. CSS og JS??
Og at IE <= v.7 ikke 'forstår' XHTML, gør da absolut ikke XHTMLs fordele teoretiske...
Mange af de ting der bliver nævnt i ranten, er fuldstændig irrelevante ift. hvorvidt man bør vælge XHTML frem for HTML.
('For the record', så er jeg dog en stor fortaler for at man bruger XHTML!)
> Clean markup makes it easier or even unnecessary to build a CMS
Arrhhh.. Content Management Systemer er nu herlige, hvis man har en side med 20+ undersider. De er jo også i bund og grund lavet til folk som ikke gider at nørde rundt med markupkoder, ligesom os.
Sidder man derimod med en side der kun er på 5 undersider, tjaah.. så er det værd at overveje om det er besværet værd.
Arrhhh.. Content Management Systemer er nu herlige, hvis man har en side med 20+ undersider. De er jo også i bund og grund lavet til folk som ikke gider at nørde rundt med markupkoder, ligesom os.
Sidder man derimod med en side der kun er på 5 undersider, tjaah.. så er det værd at overveje om det er besværet værd.
#7 - Det er jo direkte forkert -- men hvis dokumenterne bliver sendt som text/html, laver Firefox, Opera m.fl. ikke DOCTYPE-sniffing, nej. Validatoren kræver dog stadigvæk betydeligt mere af XHTML-dokumenter, fx validerer
Det passer ikke. En browser laver DOCTYPE-sniffing for at finde ud af om den skal gå i quirks eller standards compliance mode.
Quirks mode (ingen DOCTYPE):
http://www.daimi.au.dk/~u050994/browsers/doctype.h...
Standards compliance mode (med DOCTYPE):
http://www.daimi.au.dk/~u050994/browsers/doctype2....
Begge er sendt som text/html.
thedeathart har fuldstændig ret i at en browser der modtager et dokument som text/html skal parse det som HTML selvom det er XHTML. Det slår W3Cs HTML Working Group fast her:
http://lists.w3.org/Archives/Public/www-html/2000S...
Hvis Internet Explorer modtager et dokument som application/xhtml+xml så vil den forsøge at downloade det i stedet for at parse det:
http://www.daimi.au.dk/~u050994/browsers/ie/standa...
Internet Explorer understøtter ikke XHTML - den bruger blot sin fejlhåndteringsmekanisme til at vise XHTML-dokumenter sendt som text/html "korrekt". Det samme gælder Mozilla og Opera. Modtager de et dokument som XHTML sendt som text/html vil de også parse det som HTML. De kan dog godt håndtere application/xhtml+xml og parser dokumentet som XHTML.
Dokument sendt som text/html og parsed som HTML:
http://www.daimi.au.dk/~u050994/browsers/mozilla/x...
Dokument sendt som application/xhtml+xml og parsed som XHTML:
http://www.daimi.au.dk/~u050994/browsers/mozilla/x...
Det er bevidst at jeg har lavet fejl i sidstnævnte dokumenteter for at vise forskellen.
Konklusionen må være at hvis man vil lave en hjemmeside som Internet Explorer skal kunne vise, så er der ingen grund til at skrive XHTML.
Vil give folk ret i at man ikke skal skrive xhtml hvis man ikke ønsker at gøre det nemmere for sig selv senere hen.
Man kan jo blive hængende i den gamle table baserede design verden, det er jo det man kommer til at bruge i fremtiden! :D
Det er underordnet om man vælger at skrive sine sider i xhtml eller html, og artiklen som denne nyheder peger mod er skrevet af en der intet har fattet af "xhtml/css".
Men pointen med artiklen burde have været "55 grunde til at skrive semantics html og css"
Hvor pointen er at man skal skrive en sidens indhold i det element/tag der passer til hvad indholdet er.
Jeg skriver personligt kun sider i xhtml, dog som dokumenter af typen text/html.
Man kan jo blive hængende i den gamle table baserede design verden, det er jo det man kommer til at bruge i fremtiden! :D
Det er underordnet om man vælger at skrive sine sider i xhtml eller html, og artiklen som denne nyheder peger mod er skrevet af en der intet har fattet af "xhtml/css".
Men pointen med artiklen burde have været "55 grunde til at skrive semantics html og css"
Hvor pointen er at man skal skrive en sidens indhold i det element/tag der passer til hvad indholdet er.
Jeg skriver personligt kun sider i xhtml, dog som dokumenter af typen text/html.
XHTML/CSS designs har helt klart sine fordele, men teknologien lider desværre stadig af en del "børnesygdomme" og ikke mindst browser-inkompatibilitet.
Jeg er bange for at man også kan finde 55 grunde til at lade være - endnu.
Jeg er bange for at man også kan finde 55 grunde til at lade være - endnu.
Hvorfor gør folk det ikke bare? Forskellen er jo overhovedet ikke betydelig.
Er det virkelig så svært at skrive "<br />" istedet for "<br>"? Ja, der er godt nok mere end bare dét, men så meget er der heller ikke.
Desuden så er der heller ingen der siger, at man ikke må lave tabel-baserede layouts, bare fordi man bruger XHTML.
... Og hvorfor er der stadig folk som insisterer på at lave tabelbaserede layouts? Det er jo slet ikke fedt.
Er det virkelig så svært at skrive "<br />" istedet for "<br>"? Ja, der er godt nok mere end bare dét, men så meget er der heller ikke.
Desuden så er der heller ingen der siger, at man ikke må lave tabel-baserede layouts, bare fordi man bruger XHTML.
... Og hvorfor er der stadig folk som insisterer på at lave tabelbaserede layouts? Det er jo slet ikke fedt.
#13
Det er spild af tid at skrive XHTML og sende det som text/html. En browser skal parse det som HTML ifølge W3C's HTML Working Group (se link i indlæg #12). Det eneste du får ud af det er, at browseren bruger (marginalt) længere tid på at rendere indholdet fordi den skal ty til fejlhåndtering.
Jeg skriver personligt kun sider i xhtml, dog som dokumenter af typen text/html.
Det er spild af tid at skrive XHTML og sende det som text/html. En browser skal parse det som HTML ifølge W3C's HTML Working Group (se link i indlæg #12). Det eneste du får ud af det er, at browseren bruger (marginalt) længere tid på at rendere indholdet fordi den skal ty til fejlhåndtering.
#12 - Ja ok, jeg mente selvfølgelig mht. hvorvidt de skulle behandle det som et XHTML-dokument, ellers var doctypen jo fuldstændig ligegyldig for dem i HTML-dokumenter...
Ja (bortset fra det er "bør", ikke "skal") - men det han skrev var:
og det passer jo ikke, der findes mange andre mimetypes der får de tidl. nævnte browsere til at anvende XML-parseren.
Hvorfor dog? At validatoren er så betydeligt mere strict anser jeg da for at være en klar fordel, og hvis man så fx laver lidt mimetype-switching, kan visse UAs stadigvæk parse dokumenterne hurtigere, og ejeren får en nem mulighed for at tjekke hvorvidt de er well-formed.
Fx så jeg gerne IMDb sendte deres sider med en X(HT)ML mimetype til accepterende UAs (hvis de altså lige fik gjort dem well-formed først...), så det var betydeligt nemmere at finde frem til udvalgte dele af deres data...
thedeathart har fuldstændig ret i at en browser der modtager et dokument som text/html skal parse det som HTML selvom det er XHTML.
Ja (bortset fra det er "bør", ikke "skal") - men det han skrev var:
Alt (x)html som ikke har application/xml+xhtml som content-type bliver alligevel parset som html 4.
og det passer jo ikke, der findes mange andre mimetypes der får de tidl. nævnte browsere til at anvende XML-parseren.
Konklusionen må være at hvis man vil lave en hjemmeside som Internet Explorer skal kunne vise, så er der ingen grund til at skrive XHTML.
Hvorfor dog? At validatoren er så betydeligt mere strict anser jeg da for at være en klar fordel, og hvis man så fx laver lidt mimetype-switching, kan visse UAs stadigvæk parse dokumenterne hurtigere, og ejeren får en nem mulighed for at tjekke hvorvidt de er well-formed.
Fx så jeg gerne IMDb sendte deres sider med en X(HT)ML mimetype til accepterende UAs (hvis de altså lige fik gjort dem well-formed først...), så det var betydeligt nemmere at finde frem til udvalgte dele af deres data...
Det er meget nemt at sørge for at morderne browsere får "application/xhtml+xml", og at forældede browsere får "text/html".
Eksempel i PHP:
Eksempel i PHP:
$charset = "utf-8";
$mime = stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml") ? "application/xhtml+xml" : "text/html";
header("content-type:$mime;charset=$charset");
...
echo '<meta http-equiv="Content-Type" content="'.$mime.'; charset='.$charset.'" />';
#18
Det er rigtigt - eller slet ikke sætte gang i en parser (text/plain).
Fordi Internet Explorer ikke understøtter XHTML. Ligesom andre browsere parser den det som HTML hvis det er sendt som text/html. Det er vold mod browser i funktion.
og det passer jo ikke, der findes mange andre mimetypes der får de tidl. nævnte browsere til at anvende XML-parseren.
Det er rigtigt - eller slet ikke sætte gang i en parser (text/plain).
Hvorfor dog?
Fordi Internet Explorer ikke understøtter XHTML. Ligesom andre browsere parser den det som HTML hvis det er sendt som text/html. Det er vold mod browser i funktion.
#21
Ha, det vil jeg til dels give dig ret i. Problemet er bare, at Mozilla og Opera også parser det som HTML.
IE fungerer alligevel ikke som nogen fornuftige mennesker ønsker det, og desuden har den udøvet psykisk vold mod webudviklere i årevis, så jeg ser gerne dens brugere bliver straffet!
Ha, det vil jeg til dels give dig ret i. Problemet er bare, at Mozilla og Opera også parser det som HTML.
#22
Det er så der mimetype-switching kommer ind i billedet...
Men selv om jeg blev nødt til at sende siderne som text/html, ville jeg foretrække at anvende XHTML alligevel, Hixie & slængs skriverier til trods. Som du selv nævner, er den tid, browsernes HTML-parser bruger på de selvlukkende tags, kun marginalt større end ved brug af HTML (og pga. XHTMLs krav om well-formedness, kan de ligefrem være hurtigere om det indimellem). Og at XHTMLs fremtid skulle blive skadet af det, tror jeg ganske enkelt ikke på; tværtimod har XHTML netop haft den effekt, at selv almindelige folk er begyndt at interessere sig for at overholde standarderne...
Problemet er bare, at Mozilla og Opera også parser det som HTML.
Det er så der mimetype-switching kommer ind i billedet...
Men selv om jeg blev nødt til at sende siderne som text/html, ville jeg foretrække at anvende XHTML alligevel, Hixie & slængs skriverier til trods. Som du selv nævner, er den tid, browsernes HTML-parser bruger på de selvlukkende tags, kun marginalt større end ved brug af HTML (og pga. XHTMLs krav om well-formedness, kan de ligefrem være hurtigere om det indimellem). Og at XHTMLs fremtid skulle blive skadet af det, tror jeg ganske enkelt ikke på; tværtimod har XHTML netop haft den effekt, at selv almindelige folk er begyndt at interessere sig for at overholde standarderne...
#23
Jaeh, det virker bare tosset at skulle vedligeholde to sæt dokumenter alt efter om browseren kan det ene eller andet. Så ville jeg holde mig til HTML.
Jeg tvivler. Valid HTML 4 er også så godt som well-formed.
Det er så der mimetype-switching kommer ind i billedet...
Jaeh, det virker bare tosset at skulle vedligeholde to sæt dokumenter alt efter om browseren kan det ene eller andet. Så ville jeg holde mig til HTML.
Som du selv nævner, er den tid, browsernes HTML-parser bruger på de selvlukkende tags, kun marginalt større end ved brug af HTML (og pga. XHTMLs krav om well-formedness, kan de ligefrem være hurtigere om det indimellem).
Jeg tvivler. Valid HTML 4 er også så godt som well-formed.
Hvorfor er det at næsten alle der skriver her ikke fatter kernen i denne sag?
Det handler reelt ikke om man overholder html eller xhtml standarden men om man forstår at skrive semantisk korrekte dokumenter!
altså at man forstår at bruge <hx> til overskrifter og bruge dem i rækkefølge! :-)
at man forstår at 1 paragraf skal være i et element osv.
for det er i bund og grund det, det handler om.
Og når man skriver semantiske korrekt dokumenter så bruger man ikke længere tid på at lave table designs for de passer ikke ind i dokumentets semantiske layout.
#17
at jeg skriver dokumenter i sproget xhtml og gemmer dem som .html betyder at der automatisk bliver sendt en header med fil typen når man henter siden.
At jeg inde i selve dokumentet definere det korrekte DOCTYPE og mime type osv. er noget andet.
Måske det var mig der udtrykkede mig forkert.
Det handler reelt ikke om man overholder html eller xhtml standarden men om man forstår at skrive semantisk korrekte dokumenter!
altså at man forstår at bruge <hx> til overskrifter og bruge dem i rækkefølge! :-)
at man forstår at 1 paragraf skal være i et element osv.
for det er i bund og grund det, det handler om.
Og når man skriver semantiske korrekt dokumenter så bruger man ikke længere tid på at lave table designs for de passer ikke ind i dokumentets semantiske layout.
#17
at jeg skriver dokumenter i sproget xhtml og gemmer dem som .html betyder at der automatisk bliver sendt en header med fil typen når man henter siden.
At jeg inde i selve dokumentet definere det korrekte DOCTYPE og mime type osv. er noget andet.
Måske det var mig der udtrykkede mig forkert.
#26
Det er sådan set lige meget hvad du gemmer dem som. Så længe du sender dem som text/html så vil browseren parse det som HTML uanset om du har skrevet korrekt XHTML-syntaks.
at jeg skriver dokumenter i sproget xhtml og gemmer dem som .html betyder at der automatisk bliver sendt en header med fil typen når man henter siden.
At jeg inde i selve dokumentet definere det korrekte DOCTYPE og mime type osv. er noget andet.
Måske det var mig der udtrykkede mig forkert.
Det er sådan set lige meget hvad du gemmer dem som. Så længe du sender dem som text/html så vil browseren parse det som HTML uanset om du har skrevet korrekt XHTML-syntaks.
Jeg går selv meget op i at mine sider overholder XHTML-standarderne, men mange af de ting han kommer med et enormt latterlige.
44. You can use hacks and techniques with cool names like “be nice to Opera”Er det positivt at man bliver nødt til at bruge hacks for at kunne få lortet til at virke i alle browsere?
22. Promoting web standards will help your work in the future, not having to code differently to each browserUhm, jo man skal. Man skal jo lige præcis bruge nogle hacks, som du også selv skriver! :(
50. Learning to read and write it fast makes it possible to use cheaper tools (notepad)Hvad har det med XHTML/CSS at gøre?
#28
For det første - kan du ikke se humoren i artiklen? Jeg HADER "forfattere" der holder sproget og skrivestilen på et røvkedeligt journalistist niveau.
Med hensyn til hacks - jeg tror på, at vi i en rimelig nær fremtid kan kode ens til alle browsere/UAs (og dermed stoppe brugen af hacks), nemlig pga. at der er flere og flere der støtter standarderne; præcis som der bliver angivet under punkt 22. Kan derfor ikke se grundlaget for din kommentar til den sætning.
For det første - kan du ikke se humoren i artiklen? Jeg HADER "forfattere" der holder sproget og skrivestilen på et røvkedeligt journalistist niveau.
Med hensyn til hacks - jeg tror på, at vi i en rimelig nær fremtid kan kode ens til alle browsere/UAs (og dermed stoppe brugen af hacks), nemlig pga. at der er flere og flere der støtter standarderne; præcis som der bliver angivet under punkt 22. Kan derfor ikke se grundlaget for din kommentar til den sætning.
Clean markup makes it easier or even unnecessary to build a CMS
Et CMS er ikke for den der "koder" men for den der skal levere indhold.
Nej det er ikke blevet nemmere.. Måske på nogle punkter og på andre er det blevet svære...
Intet er jo svært hvis man kan det.. Men for dem der ikke kan..
Det er ikke alle der er nørder på xhtml (xml) og css området. I hvertfald ikke hr og fru danmark..
Men der er jo klart nogle forbedringer.. Men hej ville jo også være lamt hvis en nyere version var dårligere end en ældre version..
På nær lige film altså.. :)
Et CMS er ikke for den der "koder" men for den der skal levere indhold.
Nej det er ikke blevet nemmere.. Måske på nogle punkter og på andre er det blevet svære...
Intet er jo svært hvis man kan det.. Men for dem der ikke kan..
Det er ikke alle der er nørder på xhtml (xml) og css området. I hvertfald ikke hr og fru danmark..
Men der er jo klart nogle forbedringer.. Men hej ville jo også være lamt hvis en nyere version var dårligere end en ældre version..
På nær lige film altså.. :)
#12
IE med SP2 eller højere kan godt læse "ægte" xhtml dokumenter, og downloader dem ikke. Dog er IE/Firefox stadig uenige omkring loading af billeder i CDATA.
#CMS
Hvad synes i er et CMS ? Mit "cms" består af et MVC framework med 100% modulestyring of XSL templates , som derfor ikke tillader html 4.01 eller dårlig markup (du får simpelhen en fejlmeddelse, da libxml ikke har det så godt med markupfejl i parsing). CMS er et buzzword , layouts er (og vil) stadigvæk skrives i markup sprog(html/xhtml/xsl/xul), med tilhørende styring (CSS).
IE med SP2 eller højere kan godt læse "ægte" xhtml dokumenter, og downloader dem ikke. Dog er IE/Firefox stadig uenige omkring loading af billeder i CDATA.
#CMS
Hvad synes i er et CMS ? Mit "cms" består af et MVC framework med 100% modulestyring of XSL templates , som derfor ikke tillader html 4.01 eller dårlig markup (du får simpelhen en fejlmeddelse, da libxml ikke har det så godt med markupfejl i parsing). CMS er et buzzword , layouts er (og vil) stadigvæk skrives i markup sprog(html/xhtml/xsl/xul), med tilhørende styring (CSS).
#25 dbz - To sæt dokumenter? Altså, det er jo stadigvæk bare ét dokument, og man skal i forvejen hele tiden tjekke om IE nu også renderer tingene nogenlunde, selvom det fungerer i Firefox, Opera etc. Så på den måde er det da ikke værre end normalt. Hvad mener du helt præcist med det?
#31, 33 - Jeg har også tidligere hørt at det skulle være fikset med SP2, men hvis det engang var planen, blev det ihf. droppet igen; det blev først fikset til IE7B2 (måske allerede B1, men den var som bekendt ikke public).
#31, 33 - Jeg har også tidligere hørt at det skulle være fikset med SP2, men hvis det engang var planen, blev det ihf. droppet igen; det blev først fikset til IE7B2 (måske allerede B1, men den var som bekendt ikke public).
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund