.....fx skal XHTML skal parses som XML men det sker så godt som aldrig, derimod parses det som HTML men pga den modtaget DTD vil browseren allerede her gå ind og forsøge at fixe den fejl............
Det skal ikke parses som XHTML medmindre det har den korrekte DTD, MIMETYPE OG filendelse.
Jeg er ikke enig i at, uanset om vi taler HTML eller XHTML, at valid kode altid vises ens i forskellige browsere - hver browser (også Firefox) har sine fejl samt specielle egensker og dermed også hver sine ting at tage højde for. Men valid kode er klart et skridt i den rigtige retning for at få vist et dokument så ens som muligt. Target er skam også muligt i XHTML - hvis man kan nøjes med Transitional... men hov, det præcis samme gør sig gældende for HTML hvor target heller ikke er tilgængelig i Strict så ingen forskel her.
Jeg indrømmer at mit udsagn ovenfor var lidt for generelt, men jeg skrev nu heller ikke det du gengiver(understreget).
Mine 2 øverste udsagn skal ses i sammenhæng.
Jeg giver dig ret, og retter mit udsagn til.
"Der er ikke skyggen af chance for at din XHTML side bliver vist
korrekt i en XML Kompatibel browser, hvis den ikke validerer og dermed
overholder standarden.
Med XHTML side mener jeg her med korrekt doctype, korrekt MIMEtype og korrekt filtype(endelse)"
Og når jeg udvikler, så er det klart min erfaring at den lette måde er
at udvikle til browsere der overholder standarden eller det meste af
den som Opera, Firefox og Safari, sørge for at siderne validerer, og
derefter lave nogle CSS hacks for at få IE 5, 6, og 7 med. Min måde er dog ikke bedre, blot anderledes.
Som jeg forstår kommentaren omkring adskillelse af logik og markup er det jo heller ikke en umulighed i HTML - i HTML er der bare mange der har en tilbøjelighed til ikke gøre det. Men måske misforstår jeg hvad man vinder/taber her.
I mit perspektiv er det bedre at gøre det umuligt at fastholde sammenblandingen, så vi kan slippe for at alle user agenter skal forholde sig til mulige problemer med koden. Det var vel det der gjorde at alle browserproducenter indførte quirks mode under browserkrigen.
Som udvikler er der også stor forskel på at ændre en default font-størrelse ET sted i et stylesheet, eller 400 steder fordi der bliver brugt FONT alle mulige steder i koden. I mine øjne er den største gevinst ren kode der er let at vedligeholde, og der betyder adskillelsen alt.
Ligesom forskellen på struktureret kode og objektorienteret kode.
Eksperterne på området, som jeg bestemt ikke er en af, har en masse andre argumenter for adskillelsen, men det vil jeg ikke gå ind i her.
Hvilke nye muligheder er der i XHTML?
Du kan f.eks. bruge MathML, SMIL og SVG i XHTML og ikke i HTML.
For ikke at gøre det her for teknisk(vi er mange forskellige brugere), vil jeg gøre det meget kort, og ikke helt fyldestgørende.
MathML er XML til at levere, modtage og bearbejde matematik på samme måde som HTML har gjort det muligt for text.
SMIL giver mulighed for at gøre ting som kræver timing, såsom skabe slideshows, animationer m.m. direkte som HTML lignende kode.
Eksempel:
<smil>
<body>
<seq repeatCount="indefinite">
<img src="image1.jpg" dur="3s" />
<img src="image2.jpg" dur="3s" />
</seq>
</body>
</smil>
SVG betyder Skalerbar vektor grafik, og er et tekstbaseret grafisk sprog som beskriver images, sådan cirka.
Det ovenstående kan bruges nu!!!
For et ganske almindeligt website uden disse behov vil der ikke være nogen særlig forskel på HTML4.01 og XHTML1.0
Selvom jeg selv skriver XHTML og vil fortsætte med det vil det mest korrekte valg være HTML, men HTML skrevet på en måde på en måde så overgangen til XHTML bliver minimal (dvs fx brug af CSS fremfor alle mulige og umulige attributter)... og alligevel vælger jeg XHTML (:
Jeg vil godt komme med mit bud på hvordan man gør overgangen lettere også(se kogebog nedenfor), men for at kunne gøre det forståeligt hvorfor jeg vil gøre det sådan, starter jeg lige med en beskrivelse af baggrunden og problemerne med XHTML.
Jeg prøver at gøre det så lidt teknisk som muligt, da vi alle har forskellig viden på området, så beklager hvis det ikke er helt præcist udtryk.
----------------------------------
XML blev skabt for at kunne levere selv-beskrivende kode.
Eksempel:
<Navn>......</Navn>
<CPR>.......</CPR>
I XML er praktisk taget intet defineret eller erklæret før vi selv gør det.
Derfor kan det skabe forvirring for modtagerne, og vi må sende en fortolker med.
XHTML er predefineret XML, så præsentations elementerne er nogenlunde som vi er vant til fra HTML.
Den helt store forskel ses når vi vil bruge fordelene ved XML fordi vi så skal bruge den rigtige MIME type.
text/html er til HTML og XHTML der lader som om det er HTML
application/xhtml+xml er til XHTML, XML, MathML, og så videre.
Det vigtige ved den sidste linie er at der ikke er nævnt HTML.
DER ER INGEN FEJLRETNING I XHTML. Jeg gentager
DER ER INGEN FEJLRETNING I XHTML.
Det betyder at du kan sagtens skrive et dårligt HTML Document, give det doctypen XHTML1.0 og det bliver vist fint i alle browsere der behandler det som HTML.
Laver du derimod en eneste lille fejl i XHTML og viser det i en browser der behandler det som XHTML(faktisk XML), så får du noget i stil med dette når du viser siden:
########################################################################
XML tolkningsfejl: malplaceret mærke. Forventede: </img>. adresse: http://www.eksempel.dk/indhold/vis-not-valid.xhtml linje 31, kolonne 51:
<img id="head" src="imagedepot/main-top_05.gif"></div>
########################################################################
Dvs. at så længe browserne behandler det som HTML kan du tillade dig at lave fejl i koden og det går fint, men efterhånden som browserne begynder at være fuldt XML compatible, så er vi på r....
Dårligt kodet XHTML er som verdens hurtigste sportsvogn, blot uden bensin. Den når aldrig til startlinien.
Korrekt XHTML kan vandre hvor HTML ikke kan komme og udføre ting som vi kun drømmer om nu.
-------------------
Browseren OPERA og HTMLTidy er fede værktøjer til at sikre kompabiliteten. HTMLtidy kan lave HTML om til XHTML for dig.
En hurtig kogebog.
1. Lav XHTML kode, inklusive den korrekte doctype og MIME type.
2. Giv det endelsen xhtml eller xht og se om opera behandler det som XHTML og det vises korrekt, og test derefter i andre XML compatible browsere.
3. Når det er gjort, så skift endelsen ud til .htm eller .html
Nu bliver det behandlet som html4.01 og du kan debugge det i alle browserne og evt. lave nogle rettelser i CSS for Internet Explorers skyld, og i sjældne tilfælde andre browsere.
Hvis du husker at vedligeholde det som korrekt XHTML1.0 så kan du bare skifte endelsen ud når der er nok XML-compatible browsere, og det vil stadig virke perfekt.
Essensen af dette og grunden til hele forklaringen ovenfor er, at så længe browserne ikke er fuldt XHTML compatible, eller du kalder filen noget andet en .xhtml eller .xml, så vil dit website se ud som det skal, men hvis du går hele vejen og påstår at det er korrekt XHTML, så skal det altså holde.
Jeg iagttager for øvrigt at mange CMS'er og lignende nu er XHTML1.0 i de nye versioner. Det er for mig en ektra grund til at gå den vej.
------
Microsoft er for øvrigt ikke i tvivl om hvor problemet ligger mht. standard-kompatible browsere. Fantastisk hvis de holder hvad de lover.
[snip]
Microsoft's Interoperability Principles and IE8
We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we’ve posted previously.
Why Change?
Microsoft recently published a set of Interoperability Principles. Thinking about IE8’s behavior with these principles in mind, interpreting web content in the most standards compliant way possible is a better thing to do.
We think that acting in accordance with principles is important, and IE8’s default is a demonstration of the interoperability principles in action. While we do not believe any current legal requirements would dictate which rendering mode a browser must use, this step clearly removes this question as a potential legal and regulatory issue. As stated above, we think it’s the better choice.
[snip]
ovenstående uddrag er fra
http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx
------
Og så har du da ret mht. Target og HTML4.01 strict.
0)Bent