The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the <meta> element (utf-8). I will use the value from the HTTP header (iso-8859-1) for this validation.
Line 8, Column 43: there is no attribute "frameborder". <frameset rows="96,*" cols="*" frameborder="no" border="0" framespacing="0">
Line 8, Column 55: there is no attribute "border". <frameset rows="96,*" cols="*" frameborder="no" border="0" framespacing="0">
"The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the <meta> element (utf-8). I will use the value from the HTTP header (iso-8859-1) for this validation." - Dette betyder, at du ikke kan bruge tegnsættet utf-8, som du angiver i linjen: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> fordi sidens tegnsæt er iso-8859-1.
Og det med frameborder betyder jo bare, at du må slette frameborder="no". style="border:0" skulle kunne gøre det samme.
Og resten af fejlene afhænger af, hvad validatoren ellers siger. Derfor ville det være lettest med et link. =)
Ja. Problemet opstår, da siden - udover dér - er gemt i iso-8859-1. Jeg er ikke helt sikker på, hvordan dette er sket. Mit bedste bud er, f.eks. hvis du redigerer dine sider i notesblok, at du har gemt som ANSI-tegnsætning og ikke som UTF-8. Det er nemlig ikke nok at sætte charset=utf-8, det skal også gemmes som et utf-8-dokument.
Jeg har ikke selv dreamweaver, men et eller andet sted, kan det sættes. Hvis du nu prøver, for sjov, at ændre utf-8 til iso-8859-1 og validerer igen, forsvinder den fejl så ikke?
The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the <meta> element (utf-8). I will use the value from the HTTP header (iso-8859-1) for this validation.
Din webserver fortæller at dokumentet er iso-8859-1, fordi den er sat op til at bruge det som standardtegnsæt, og du intet gør for at override headeren server-side. HTTP headeren har altid prioritet over et <meta>-element, så du skal have fat i konfigurationen på din webserver, eller smide noget PHP/ASP/whatever ind for at ændre headeren.
 er netop grunden til at Notepad ikke bør bruges til UTF-8 - det er et Unicode BOM omdannet til UTF-8, men det gavner udelukkende til identifikation når det er UTF-8 (eftersom byte ordering ikke er et problem).
Stort set alle andre Unicode-kompatible editorer benytter ikke et BOM ved UTF-8, eller tilbyder at gemme enten med eller uden. Jeg bruger selv Vim, men Notepad++ skulle også kunne, og er nok mere brugervenlig. *-)
Hvis det er  fejlen du stadig får, så gem din fil som ANSI i Notepad igen. Netop i dette tilfælde er der ingen forskel på ISO-8859-1 og UTF-8, og på den måde kommer du nemt af med det BOM.
The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the <meta> element (utf-8). I will use the value from the HTTP header (iso-8859-1) for this validation.
w13: border:0; laver desværre alligevel border. Andre forslag?
Hmm... Det er vel ikke en ren HTML-fil (altså ikke en .php-fil)? PHP kan jo ikke gøre noget ved en fil hvis den ikke sendes igennem den - der slår Apache/IIS' konfiguration i stedet igennem (og den står nok også til iso-8859-1 som standard-tegnsæt).
Alternativt kan det være at der lige går lidt tid før dine ændringer slår igennem - afhænger af din host.
Men det giver ikke megen mening at blande en oldnordisk ting som frames med XHTML. Den eneste årsag til det overhovedet kan vises, er at koden tolkes som HTML ... og så forsvinder jo den sidste rest af grund til at reklamere med, man kan læse en manual og gøre nogenlunde, som der står (W3C-bannerne) ;o)
Ole, af ren nysgerrighed, hvorfor ville et (validt) dokument med den doctype fejle hvis den blev parset som XHTML? Jeg er ikke sikker på jeg kan se sammenhængen (selvom jeg nu også ville vælge HTML 4.01), når nu det er en egentlig doctype.
akyhne, når jeg kører din oprindelige kode gennem validatoren, er den eneste fejl på selve framesene at du har brugt scrolling="No" (i stedet for det rigtige scrolling="no"). frameborder findes som attribut på frame i XHTML 1.0 Frameset (derfor rykker du den derned), men border gør ikke og framespacing gør ikke.
Derudover skal <noframes> ind i dit frameset før det er gyldigt.
Jeg fandt ud af hvordan jeg kunne bruge include til et subdomæne, så jeg går måske over til tables eller andet.
Problemet er at siderne ligger således i forhold til hinanden: /home/www/forum.e-debatten.dk /home/www/e-debatten.dk
Da jeg ikke kunne kalde subdomænet som hos andre hosts på denne måde, e-debatten.dk/forum/index.php, fandt jeg ud af at jeg bare kunne gøre således: <?php include('../forum.e-debatten.dk/index.php') ?> Jeg kan altså tilsyneladende godt gå et længere skridt tilbage end selve roden!
- vil du se, dokumentet bliver served som 'text/html'. Det skal alle XHTML 1.0 flavours (som ikke er Strict) sendes med - og de kan derfor aldrig parses som andet.
w13, jeg tror problemet er at det netop IKKE er en .php, men en .html :)
Så længe du ikke har et tegnsæt angivet i din HTTP header (det er så Apache's konfiguration mht. standardtegnsæt der er tale om her), kan du bruge <meta> til at angive det, og effekten skulle være den samme (bare sørg for at placere det i starten af din <head>).
Hvis Apache derimod siger det er en iso-8859-1-side, vil det have prioritet over din <meta>, og derfor vil du være nødt til enten at omdøbe til .php (og så bruge PHP-løsningen med header), eller også må du få ændret Apache's konfiguration til at bruge UTF-8 som standardtegnsæt. Jeg mener det er en af de ting der kan håndteres via en .htaccess, men jeg er ikke 100% sikker.
Jeg har nu heller ikke brug for det, men var bare nysgerrig.
Men kort sagt: Hvis min udbyders server som i dette tilfælde er en Debian server med Apache installeret, er det serveren der i princippet bestemmer hvilken charset jeg kan køre med, sålænge vi snakker html. For PHP siders vedkommende, kan det klares, enten ved at lave en .htaccess, eller evt. ved at rette i de muligheder jeg har i php.ini.
Jeg fik det til at virke med linien "AddDefaultCharset UTF-8"
Det var dog ikke uden prolemer. Tror I for pokker det er muligt i Vista at omdøbe en fil til et navn med kun extension! Næh, så let skulle det ikke gå. Jeg måtte i CMD med administratorrettigheder, og omdøbe den med Rename!
Jeg prøvede i øvrigt først med "AddCharset UTF-8", men det gav en "Internal Error 500", både via W3 og på selve siden.
Iøvrigt er jeg forlængst gået fra frameset, og har flyttet siden til http://www.e-debatten.dk. Det krævede nogle indgreb i de originale SMF filer, men det var den eneste løsning der gav det jeg ville have.
Og lad nu være med at skælde ud over at jeg bruger tables i stedet for layers. Det virker nu engang for mig :-)
Der var i øvrigt ikke nogen af Jer der kommenterede mit spørgsmål 19/02-2008 00:19:17 olebole er da i hvertfald ikke debatløs, så han må da synes det er en god ide ;-)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
