fejlteksten This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute)
giver den ikke et hint om at skifte første linje i html-koden ud med <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Egentlig står der vel ud for alle fejlbeskrivelserne hvad man skal gøre for at løse problemerne. Hvis ikke er står det direkte kan man altså slå op efter det pågældende objekt. Fx: http://www.w3.org/wiki/HTML/Elements/param
Har du prøvet, som der står at tilføje værdierne med CSS i stedet?
@claes57: Jeg vil jo mene jeg allerede har den linje - hvis du kigger i kildekoden for siden kan du se det.
@Kjeldsted: At tilføje værdierne med CSS - er det ikke det samme at bruge styles='' ? Kan ikke rigtig se på det link du kommer med, hvordan det ellers tilføjes via CSS ?
Til en begyndelse, giver det ikke mening at skrive XHTML 1.0 Transitional. Meningen med den var, at den var en midlertidig version, vi skulle bruge, mens vi en kort overgang øvede os i rigtig XHTML ... tilbage omkring 1999-2000. Det gælder forøvrigt alle Transitional flavors, så DTD'en i #1 er endnu mere forældet og kan heller ikke anbefales.
I virkemåde er der ingen forskel mellem XHTML 1.0 Transitional og HTML 4.01, så du og dine brugere har intet ud af XHTML-syntaksen.
Derudover har W3C forlængst (i sommeren 2009) stoppet udviklingen af 'XHTML X.X serien' og har i stedet helliget sig arbejdet med HTML 5. Man kan godt bruge HTML 5 med XHTML-syntaks, men med mindre du har helt specielle behov og i forvejen bruger XML i siden, har du ikke noget at bruge XHTML-syntaks til =)
Derudover er dine fejl, så vidt jeg kan se, helt grundlæggende forståelsesfejl omkring HTML/CSS:
Et PARAM er et 'usynligt dataelement', som det ikke giver mening at style. Derfor kan det naturligvis ikke have en style attribut.
Et PARAM element kan kun være barn af et OBJECT- eller APPLET-tag. Det kan ikke være barn af et DIV.
EMBED elementet eksisterer ikke i (X)HTML før version 5. Men det står der jo ret tydelig information om i valideringesdokumentet.
Mht. at begynde at ændre på XHTML 1.0 Transitional: Det kan jeg ikke tillade mig, da der er tale om CMS systemet PHP-Fusion. Jeg kan/vil ikke begynde at ændre på noget som de kører med som standart. Jeg kan jo ikke ene mand sige "Hey ændre lige på det der" - når der er mange hundrede tusinder brugere der kører med det standart som det er nu.
Anyway - det var bare et tema jeg havde fået en gut til at lave for mig - et tema som jeg evt. ville have betalt for, men har afslået da jeg ikke kan få det skidt med flash til at validere.
Udover det så forstår jeg mig slet ikke på div-baserede temaer, så jeg skruer selv et tabel-baseret tema sammen nu.
Hvis I alle tre smider et svar vil jeg dele point imellem Jer.
Tak for Jeres svar på trods af jeg ikke forstår dem.
"Udover det så forstår jeg mig slet ikke på div-baserede temaer, så jeg skruer selv et tabel-baseret tema sammen nu."
Kan man tillade sig det, når der nu sidder hundrede tudinder af brugere, som med rette forventer, at deres leverandører af webindhold efterhånden burde have lært at skrive moderne kode til moderne browsere.
CSS til layoutformål erstattede tabeller til samme brug (en anvendelse tabeller i øvrigt aldrig havde været tiltænkt) tilbage i slutningen af 1990'erne. Det må efterhånden være 'half-past' på høje tid at få det lært! *o)
Hvad angår point, så samler jeg ikke. Dem må de andre dele - men tak for tilbudet =)
"Kan man tillade sig det, når der nu sidder hundrede tudinder af brugere, som med rette forventer, at deres leverandører af webindhold efterhånden burde have lært at skrive moderne kode til moderne browsere." - det kan man måske ikke - jeg ved det ikke. Jeg står så heldigvis heller ikke for design/tema-afdelingen i det regi... ;-)
der er lige denne "Anyway - det var bare et tema jeg havde fået en gut til at lave for mig - et tema som jeg evt. ville have betalt for, men har afslået da jeg ikke kan få det skidt med flash til at validere."
Jeg vil synes, at du må betale hvis du kasserer det - det er jo ikke sikkert, at det er temaet, der gør, at du ikke kan få koden til at validere. Det kan være at der slet ikke er nogle temaer, der validerer. Ellers må du give fyren en chance for at rette koden - uanset om du forstår div'er eller ej.
der er så, hvordan vi opfatter et tema - jeg ser det som ren design (farver/kanter) lagt ind i et standard-cms. Hvis standard-cms ikke kan validere, så kan man da som køber ikke forvente, at tema-designeren skal rette hele cms-koden til.
Jeg vil derfor gerne se, om en hvilket som helst (på nær det bestilte) standard-tema til dette cms kan validere. Hvis ikke, så vil køber have noget, som sælger ikke kunne være klar over - og hvis det ikke er specificeret inden som ultimativt krav, så skal det betales. Og tema har så intet at gøre med, hvad kunden bagefter vil køre ind af sider i temaet (fx flash-video) - det må være kundens problem at få html-kode til at virke i et standard-cms. Ellers skulle sælger lave samtlige sider, og kunden må ikke pille ved koden/siderne efterfølgende (det er jo ikke, at så snart kunden har et problem, så kan trække betalingen tilbage).
Hvad årsagen er til, at man ikke kan skrive valid kode, er i min verden ikke interessant.
Lever et CMS ikke op til professionelle standarder for faget, bør man som indholdsudbyder vælge et andet, som er i orden.
På samme måde mener jeg ikke, man som håndværker bør spilde tid på at skrive temaer til software, som ikke lever op til standarderne - og man kan slet ikke tillade sig at tage penge for det.
@claes: "Jeg vil synes, at du må betale hvis du kasserer det - det er jo ikke sikkert, at det er temaet, der gør, at du ikke kan få koden til at validere. Det kan være at der slet ikke er nogle temaer, der validerer. Ellers må du give fyren en chance for at rette koden - uanset om du forstår div'er eller ej."
Det er nu temaet det er galt med - det flash bruges netop i headeren i temaet. Og jo, stort set alle temaer validerer når man downloader dem fra PHP-Fusion. Desuden har jeg da selvfølgelig snakket med fyren omkring at rette det - men det kan han desværre ikke. Desuden har jeg skiftet tilbage til et standart tema på www.v70205.dvdside.dk testsiden - så kan du jo samtidigt se at det tema validerer - ligesom stort set alle andre temaer gør det. Kan da nok høre du ikke giver en s*** for det her CMS.. ;) - men så er det godt vi er andre der gør det.
. o 0 (..tænker jeg nok aldrig skulle have spurgt herinde alligevel..)
Når vi nu er ved det; Er godt klar over der findes EKSPERTER herinde, men mange gange er det altså ikke særligt rart at spørge om hjælp herinde. Har oplevet det før - at man nærmest bliver sablet ned. Synes I skulle tænke over at dem der spørger om hjælp nok ikke er eksperter..
Der er ingen, der har 'sablet dig ned'. Du må lære at se forskel på saglig kritik af en kode (oven i købet en, du ikke selv har skrevet) og personlig kritik.
Det første må man forvente, når man spørger - og spørger man kompetente mennesker, har man vel mere eller mindre krav på det. Det sidste skal man ikke finde sig i - men det har du heller ikke været udsat for =)
ok - det er en fejl i tema - og så skal du ikke betale... Jeg ville bare sikre, at du ikke stoppede betaling af den forkerte grund, så du og tema-udvikleren blev uvenner. Problemet ligger ikke i PHP-Fusion - så er det på plads.
Med hensyn til noget som resulterer i HTML der ikke validerer, saa skal man lige vaere opmarksom paa, at: - det giver ikke noget godt indtryk af den faglige ekspertise bagved - men chancen for at kunne slippe for at skulle betale udelukkende p.g.a. dette vil vaere taet paa nul, at slippe ud af en kontrakt vil kraeve at der kan paavises reelle problemer
Arne, vi er helt enige om din første pointe. Hvad angår den anden, har du uden tvivl ret. Fagene i branchen er for manges vedkommende meget unge - hvorfor det i mange hjørner kniber gevaldigt med faglighed, faglig identitet og etik.
Indenfor husbyggeri er det ikke nødvendigt, at væggene ramler ned om ørerne på køberen, for at vekommende kan få medhold i, at evt. fejl i det mindste skal udbedres på sælgers/bygherres bekostning. Det gælder stort set alle håndværkerfag, fordi de er gamle nok til, at de har fået opbygget en faglig holdning til, hvordan faget skal udøves - og at de har fået etableret fungerende 'syn og skøn' faciliteter.
Der er ikke mange fag, hvor man med største selvfølgelighed forventes at finde sig i selv de allermest basale fejl i forhold til fagets tekniske standarder. Og det må man vel kalde markup-fejl i webudvikling.
Du har, som sagt, uden tvivl ret, men jeg finder det ynkeligt for branchen, at det står sådan til - og jeg er ikke i tvivl om, at det skader udvikling af fagligheden.
Ved en konference om kvalitet i software udvikling startede foredragsholderen med at bede tilhørerne om at række hånden op, hvis de i tilfælde af at de sad i et fly der var klar til afgang og de pludseligt blev klar over at flyet blev styret af software som de havde været med til at udvikle så ville forsøge at komme af flyet. Alle pånær en rakte hånden op. Foredragsholderen spurgte så vedkommende om hvordan de sikrede en kvalitet der gjorde, at han turde flyve med deres software. Personen svarede at med deres software kvalitet så var sandsynligheden nul for at de ville komme fra gaten og ud til startbanen.
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.
