27. april 2013 - 22:00Der er
11 kommentarer og 1 løsning
Forskellig tolkning trods validering
Jeg troede, at valid kode garanterede nogenlunde ens udseende i forskellige browsere. Men på denne side: http://www.web-legestuen.dk/blogmodul/brugerflade.php ændres flere ting i forskellige browsere: Alt ser godt ud i IE, men i Firefox ændres højde og bredde på input-felter og i Crome forsvinder file-felter helt og tekst på "gennemse"-knappen ændres til "vælg fil".
Jamen, det har du så forstået fuldstændig korrekt: Valid kode garanterer nogenlunde ens udseende i forskellige browsere =)
Det undrer mig lidt, du bruger XHTML 1.0 Transitional. Den version var tilbage i 1999 ment som en midlertidig overgangsversion, mens vi lærte den nye syntaks - inden vi kastede os ud i rigtig XHTML. XHTML 1.0 Transitional vil aldrig blive parsed som rigtig XHTML af nogen browser.
W3C opgav at videreudvikle XHTML i 2009 - og du har ikke rigtig noget at bruge XHTML til på siden, så du burde nok vælge en anden version - f.eks. HTML5.
Det ser også ud til, at du ikke rigtig kan blive enig med dig selv om charset'et. De facto standard på nettet er i dag Unicode og på vores breddegrader utf-8.
Det er vigtigt at forstå, at valdid kode ikke nødvendigvis er god kode - men god kode er altid valid.
Visse ting er ikke specificeret i standarderne. Det er således i høj grad op til implementeringen, hvordan INPUT elementer renderes. Der er ikke fastlagt regler for bredde, højde, padding, margin eller border, så det varierer fra browser til browser.
Hvad der står på din knap, kommer an på browser og sprogversion. Hos rigtig mange står der 'Browse...' - det kan du ikke vide.
Størrelser kan du til en vis grad styre via CSS, men der vil altid være små forskelle. Også mellem de enkelte elementer i den samme browser. Sætter du et INPUT[type=text], et TEXTAREA og et SELECT element til en bredde på 200px, vil de i flere browsere afvige få pixels fra hinanden. That's life =)
Valid kode garantere ikke nogenlunde ens udseende i forskellige browsere.
For eksempel <input type="file"> den har det med at se forskellig ud i de forskellige browsere. I Safari og Chrome ser den omvendt ud hvor knappen er til venstre og filnavnet til højre. Så det er ikke fordi input feltet ikke vises i Chrome det ser bare sådan ud.
Den lette måde at rette det på er ved at give dine <input type="file"> lidt mere plads i bredden så de kan vises fint i alle browserne.
->ole: Doctype blev simpelt hen valgt udfra hvad jeg så og læste på forskelige sider; ligeså fha charset. Sådan er det med absolut newbies. Vi kan kun blive klogere. Nu er <!DOCTYPE html> sat ind i stedet. Hvor stor betydning har det at tegnsættet stadig er charset=iso-8859-1?; jeg kan nemlig ikke se, hvor jeg kan ændre tegnsæt i min editor.
->scootergrisen: Jeg var ikke klar over, at der var så store forskelle. Men er lidt glad for, at det ikke er mig, der er helt galt på den. Jeg har prøvet at ændre bredde på input-felter, og det præsenterer bedre.
Tak for hjælpen begge to. Læg et svar og del point.
@scootergrisen: Hvis du nu kunne påvise adskillige og store forskelle, som under normale omstændigheder opstår i valide dokumenter, ville din kommentar ikke fremstå som vrøvl. Valid kode garanterer nogenlunde ens udseende i forskellige browsere *o)
Undskyld, men at teksten på file-input'ets knap er sprogafhængig og derved ændrer størrelse, kan da aldrig have noget med kodens validitet at gøre. At teksten skifter med brugerens sprog er en feature. Opstår der problemer omkring dét, er der tale om et designproblem - ikke et problem, vedrørende koden eller dens validitet. Ja, af uransagelige grunde har WebKit (Safari og Chrome) valgt at lægge knappen i 'den anden side', men det burde næppe heller skabe store problemer.
Derudover er file-input'et i udgangspunktet et element, som potentielt indebærer meget seriøse sikkerhedsproblemer. Derfor har det traditionelt været mere 'isoleret' fra indgriben fra udviklerens side - herunder styling og scripting.
Et andet element, som gennem tiden har skabt store problemer for mange designere, er SELECT. Det skyldes, at noget af elementet har sin oprindelse i browserens renderingsmaskine, mens andet (popup'en) kommer fra maskinens OS. Det gør, at styling-mulighederne er ret begrænsede.
Når man skriver valid kode og bruger en doctype, som sætter browseren i 'standard compliant mode', er forskellene mellem de forskellige browsere absolut minimal. Forskellene begrænser sig til ganske få pixels i INPUT-dimensioner samt lidt omkring padding/margin på UL og P elementer. Ikke noget, som burde skabe væsentlige problemer.
Generelt er det min erfaring, at langt de fleste sites har væsentligt større problemer med indholdet end de har med formelementers rendering =)
Ellers tak, jeg samler ikke point, så enten må de være scootergrisens eller også lægger du bare selv et svar og accepterer det =)
olebole > Du laver bare en side med <video src="video.ogg">ikke understøttet</video> også prøver den i forskellige browsere og versioner så får du se at selvom koden er valid så giver der forskelligt resultat.
Du vrøvler Big Time! Det element, du fabler om, hører til i en standard, som har status af 'Candidate Recommendation' - en standard, som er 'work in progress'.
Måske, det er på tide, du prøver at sætte dig lidt ind i HTML5, og hvorfor dén standard skal behandles på en helt anden måde end andre af W3C's standarder.
Derudover er det klart, at når man bruger en browser, som ikke understøtter en bestemt teknologi, så vil den browser naturligvis vise en side anderledes end browsere, som understøtter den teknologi.
Hvis en klient således ikke understøtter Flash, vil en side med Flash naturligvis ikke vises sådan, som den vises på andre klienter - uagtet, at player'en er implementeret med et validt element.
Bare du kan bestemme dig. Først siger du at valid kode vises ens og nu siger du at det ikke vises ens alligevel.
Hvis valid kode blev vist ens så var der nok ikke så meget ballade med at det ser forskelligt ud i de forskellige browsere.
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
Ny bruger
Nybegynder
Opret
Preview
