Den varme kartoffel: webudvikling - XHTML 1.0/1.1 vs. HTML 4.01 Strict?

Jeg benytter begge dele.

Min holdning er at alt hvad jeg laver skal validere, og hvis det validerer okay, er der ingen forskel på hvordan det ser ud i forskellige bruger agenter (browsere).(med enkelte undtagelser- Microsoft)

Validerer det derimod ikke, så vil alle browsere reparere HTML på forskellige måder, hvilket kan give forskellige resultater mht. udseende, hvorimod browserne ikke prøver at reparere XHTML.

Har du ikke brug for de nye muligheder der er i XHTML er der ingen grund til at bruge det, bortset fra den rene adskillelse af logik og Markup(formatering) som jeg godt kan lide.

2 problemer med XHTML1.0 jeg har mødt.

Jeg kan ikke bruge attributten target til en reference, så jeg er nødt til at bruge lidt javascript/jscript hvis jeg vil  åbne på en ny side. Det er jeg ikke så vild med.

Hvis du indsætter den korrekte kode til at fortælle hvordan det skal fortolkes, så vil IE have en anden kode end f.eks. Firefox, og det betyder at siderne ikke bliver behandlet som XHTML1.0 i IE.

Jeg har imidlertid ikke haft problemer med at få det til at spille ordentligt, og da jeg forventer at der går mange år før browser-leverandørerne tager et klart valg af at understøtte hele standarden, så tager jeg det helt roligt mht. valget.

Hvis dit udgangspunkt er et system med templates i XHTML så kør videre med det, og er udgangspunktet HTML så fortsæt med det.

Det er måske værd at være opmærksom på at det er tvivlsomt om dine CSS3 koder bliver udført uanset om doctypen er XHTML da de fleste browsere ikke har implementeret understøttelsen endnu, så vidt jeg er orienteret.

Jeg er ikke sikker på at XHTML1.1 er implementeret af nogen browsere overhovedet dags dato.

EDIT:
Jeg kommer lige i tanker om noget der kunne gøre en stor forskel.

Hvis brugerne kan tilføje input, så skal det saniteres ordentligt før det gemmes, da det i hvert fald teoretisk kan knække XHTML1.0. Dvs. at man kan risikere at hele siden ikke vises pga. dårligt input. Jeg kan ikke lige sige om det gælder faktisk, men det gør det i hvert fald i teorien.

;0)Bent

keysersoze:

.....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.

keysersoze:

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.

keysersoze:

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.

keysersoze:

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

keysersoze:

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

Beklager. Siden meldte fejl, så jeg indsatte indlægget igen. Forsøger mig med at slette det nu.